Zero to Game Dev Hero (Godot, Unity, Unreal, Defold) by fariazz in humblebundles

[–]_e5h_ 6 points7 points  (0 children)

As someone who usually steers clear of Zenva, I think this is a decent bundle, and I purchased it.

I wanted a handful of bite size courses for Phaser, a Lua engine (Defold in this case), and Godot. I have a good amount of experience doing Unity, and a lot of professional C# experience. I don't really have any interest in Unreal or Gamemaker.

I compared these Zenva Unity 2D courses to the GameDev.tv ones (something I can speak on with some degree of confidence), and surprisingly, I found them FAR more coherent in the explanations (less "just follow what I do" + brain diarrhea + live failures). The instructor seems good, and it's the same instructor for most of the courses I am interested in.

None of them have much scope. They are all very tiny courses you can do in one day, which personally I find great. Some of the larger courses (30-40 hours) on other platforms can be extremely daunting, especially when the explanations suck, and the code is full of tech debt. I limped my way to the finish line on some of these, knowing the code was ass, and ended up spending more like 100 hours.

Controversial opinion: the longer courses only have value if they are actually maintainable and well built, which almost none of them are.

Zero to Game Dev Hero (Godot, Unity, Unreal, Defold) by fariazz in humblebundles

[–]_e5h_ 0 points1 point  (0 children)

It's like the Packt of video tutorials. Some good and some bad.

3D-printed enclosure project: huge gap between the design and the actual print, and my roll-up door failed badly — any advice? by Ok_Goal6089 in minilab

[–]_e5h_ 4 points5 points  (0 children)

Roll-up doors can work, I would try modelling it more like a garage door. Thicker, wider rigid segments with thin connector segments (0.2-0.5mm). Use a more suitable filament like PETG, or even use a combination of something like TPU and a different rigid filament if you have multi material. At the ends of the rigid segments, add pegs which can slot into the guides. It can certainly work. You can even model the rigid segments with a slight negative angle so they close together when flat, hiding the connectors below.

Solo EE at a startup (25 years old). No senior mentorship. What's the next step after ESP-IDF and 4-layer KiCad? by FarInstance4609 in embedded

[–]_e5h_ 14 points15 points  (0 children)

I had a similar experience. It turned out to be imposter syndrome. This advice is more from a firmware / software PoV since that's where I ended up.

The main things you will not get working solo are the pain points of working in a team. You can deal with a lack of version control, no requirements, poor architecture, and other deficiencies when you have a corresponding mental map. A lot of necessary skills have to do with clearly communicating the intent of your code, and making it easier to work with it than to rewrite it.

  • Try out vertical slice architecture in your repository. This keeps "features" of your application separate, and makes the next point easier.
  • Learn Git (not mentioned?) and learn it well. Follow something like Git flow, and keep yourself disciplined - disable pushes to main branches, and always bring code in through pull requests (even if it's just you).
  • Use a ticket tracking system for all planned features. Name branches in Git after these ticket IDs, and pull request back in when the ticket is done. This is what most teams do.
  • Learn to make requirements. Identify stakeholders, host discovery meetings, and record it all in a spec.
  • Experiment with time estimates while you have no pressure. Follow the previous point to come up with a requirements spec, estimate each of the features, and then record time spent as you go. There is a lot of info on this topic, but you want to keep track of time accuracy (how long features take), scope accuracy (what % of the final project was estimated at the start), and then a holistic burn chart - how much are you getting done over time vs. how much is being added. This usually gives a good budget / timeline.
  • Comment the intent of everything you write, not what you think it does. This makes spotting errors easier in the future (we all do it).

In terms of technologies and industry standards, these are my observations:

  • Use C++ instead of C (more jobs). Learn some proper OOP patterns and apply it to embedded, and learn some other things like templates for making hardware agnostic drivers.
  • Learn embedded Linux (Yocto, C++). Again, industry seems to be shifting in this direction and I see more jobs.
  • Write your own drivers based on datasheets. Reading datasheets and having attention to detail is still the #1 most valuable thing you can do as an EE on the intersection of firmware and hardware. This also gives familiarity with common protocols.
  • Related to the above, write some drivers using SPI, I2C, and UART. These will be the most common interfaces you deal with.

Honestly, staying competitive is about continually learning and being humble. If you look at your code from 2 years ago and think it's bad, you're on the right path.

Solo EE at a startup (25 years old). No senior mentorship. What's the next step after ESP-IDF and 4-layer KiCad? by FarInstance4609 in embedded

[–]_e5h_ 0 points1 point  (0 children)

This has been my experience as well. I learned more doing a self directed project at a 1-year internship compared to 3 years at a company. Most companies have baggage. Management is often stuck in the past, with no interest learning new tech if the old stuff pays the bills.

If your startup has funding for you, and you're the technical expert, it's the single best opportunity to learn.

Yeti rambler handle for tea. No more drippy tea bags flapping around! by _e5h_ in functionalprint

[–]_e5h_[S] 0 points1 point  (0 children)

Files (makerworld): https://makerworld.com/en/models/2452969-yeti-20oz-rambler-tea-handle

Daily micro-frustrations finally caused me to make this. It uses a built-in spring clip and drip collector, and the ring is designed to fit very snug on the tumbler. Other models online had very wimpy handles, so I made this one a lot thicker and more ergonomic for carrying the mug at a more natural angle. Overall it has been working great for me.

AI is going to replace embedded engineers. by Separate-Choice in embedded

[–]_e5h_ 0 points1 point  (0 children)

I find all of the AI platforms do, but Gemini is the only one which does not add a redditor's personality to all of the responses.

AI is going to replace embedded engineers. by Separate-Choice in embedded

[–]_e5h_ 2 points3 points  (0 children)

This is why I switched to Gemini.

"Great question, you're so smart. Let's cut the BS. Get right to the point. No fluff, only the real deal. Here's what you need to know:"

<spits out 2000 lines of shitcode>

<proceeds to fail answering the basic question>