Blake Haugen

Hiring software engineers is fundamentally broken. We hire them based on how well they can solve arbitrary technical challenges. Then they start their job and task them with navigating ambiguity. It's asking a ton of questions to clarify the task and then making trade-offs about what to do or not do. There is no logical answer. Just a lot of ambiguity. That is the real job. You need to interview developers based on how well they handle that ambiguity. Not how well they solve arbitrary puzzles you can ask AI to answer on the first day of the job. Hiring people who can solve real user problems and navigate ambiguity has always been a critical skill. Now it is the key in the era of AI.

2,694

214 Comments

My hot take: Using generative AI to generate code is actually helping senior engineers more than junior engineers. You see, as senior engineers we know our stuff, and we're just lazy. Want to write minimal test cases for our modules? Yes we can do it. But we're lazy, so we just ask our favorite genAI tool to write the initial code for us. That's the keyword: initial code. Because in my experience, even genAI can make mistakes and sometimes the code is just weird. The good thing is, we know what we're asking for, so we can make some adjustments to the code and make it work and make it better for our projects. For example, I'm too lazy to think of the common cases for testing my FIFO module, so I ask ChatGPT: "generate 10 unit test cases for my FIFO module. I'm using Catch2 framework" Because we know what test cases should look like, we can verify its output. If there's any weird output, simple, we tweak the output. Done. It's a different world when a junior embedded engineer tries to do the same. I was once checking my mentee's work, he was trying to use GenAI to help him solve an issue. It was countless retries of generating code. I could see he didn't understand what the code did. From there, I realized that genAI will only help experienced engineers finish boring tasks, it's like delegating tedious work to an intern, and we check for the result. For beginner engineers, genAI will do more harm than good. Simply because they can't verify the AI answers. They would blindly copy the output code and get stuck when it didn't work as expected. So what's the solution? Treat generative AI just like an intern with internet access (because it is). They can find the information, but it's your job to verify its result. It's a good tool for finding good ideas, but it's not your expert. Because the one that SHOULD be the embedded systems expert is YOU. How's your experience with genAI in embedded systems?

137

16 Comments

🚨 Hot take: DRY (Don’t Repeat Yourself) is a lazy shortcut, not a design principle. Too many engineers hide behind DRY as an excuse to over-abstract, over-engineer, and shove unrelated logic into one place. The result? Rigid, tangled codebases nobody wants to maintain. Here’s the problem 👇 DRY directly clashes with SOLID, the principles that actually keep systems clean:  • SRP (Single Responsibility Principle) → DRY forces unrelated responsibilities into one place.  • OCP (Open/Closed Principle) → DRY makes code harder to extend without rewriting.  • ISP (Interface Segregation Principle) → DRY pushes fat interfaces instead of focused ones. Meanwhile, SOLID scales everywhere:  • At the code level → clean classes and methods  • At the system level → well-designed microservices 👉 Duplication isn’t evil. Complexity is. Sometimes copy-pasting is the more SOLID, maintainable choice.

99

3 Comments

I’ve noticed an interesting shift in my dev habits over the last few months. I’m doing less and less notebooks and more just pure py files. You might ask why? A few reasons: - uv makes it brain-dead easy to create virtual environments and run py scripts - when I do get an error, restarting the Jupyter kernel takes longer than me just rerunning the Python script from terminal - my dev code is becoming cleaner and less all over the place - no more copy-pasta the code from the notebook over the py when I’m ready to move up to prod. #dataengineering

46

28 Comments

There’s a quiet trend happening - Rust engineers leaving comfortable FAANG roles for small, high-ownership teams. Not because they want ping-pong tables or startup chaos - but because they want meaning. They want to build things where their fingerprints actually show up in the product. Every week I hear the same line: “I just miss building.” That’s why early-stage Rust hiring is taking off. The best engineers want to feel the impact of their work again. If you were choosing between stability and impact, which way would you lean right now? 🦀

86

11 Comments

"Engineers need very specific requirements." I overheard this today, thankfully not from someone at my company. But it pissed me off. This statement implies that software engineers can't think through complex and ambiguous customer problems, that they need someone to carefully prepare very specific widget designs for them to build. That they can't figure out the very specific requirements themselves, if necessary. I suppose if the requirements weren't specific enough, they might ask questions! Questions that only the customer can answer! And maybe not even them! And then maybe they would have to figure it out for themselves and iterate on an idea until the customer is satisfied! Oh no! I'm sure the person who said this was acting in good faith, but siloing engineers off and only feeding them "requirements" robs them of the opportunity to understand and solve the real problems and have real impact. It also wastes time with unnecessary feedback loops. Worst of all, it holds them back from growing into more product and business-oriented directions, which can have a negative impact: on their careers. The next time someone tells you that engineers need very specific requirements, don't argue. Just ask to invite the engineers to the next meeting to discuss the requirements with them directly. Bring them into the process. If you get pushback, go to the engineers directly. The best software engineers I know would appreciate it.

104

24 Comments

If an LLM can replace your junior engineers, you are a terrible boss. I've worked with dozens (maybe more than a hundred) of junior engineers (and CS/engineering students) over my long career in software development and software engineering. Junior engineers are just as smart, just as creative, frequently even more hard working, than any senior engineer, all they lack is experience. If you are giving your junior engineer low-level tasks, you are doing it wrong. Junior engineers can solve senior problems, with a little help and guidance. A few months (or even weeks) of good guidance can turn a junior engineer into a serious contributor. They need serious tasks, and serious responsibility. There is no "boilerplate" code in well-engineered solutions. There is no easy part, because the easy parts have all be solved already. If you are assigning work to junior engineers which can easily be done with an LLM, then you are seriously under-utilizing your talent. Maybe such managers should be replaced with LLMs...

142

7 Comments