Hacker News Reader

Comment by ryukoposting | Hacker News Reader

SOLID is a meaningless term in my corner of the industry (firmware, where we follow the SPAGHETTI method), so I read SOLID as a placeholder for whatever the acronym-of-the-week is. With that in mind, I came to a totally different conclusion. I want to ask questions that most interviewees get wrong, because that's how you narrow down a large pool of candidates to a small pool of finalists. Augmented by a reasonable quantity of questions, pointed questions like these can serve to isolate a signal from noise.

View on HN

> firmware, where we follow the SPAGHETTI method

I used to write GPU device drivers. Electronic Engineers had a great understanding of the hardware, but tended to write sloppy spaghetti code. CS graduates, on the other hand, had a loose grasp of the hardware but we're better at writing solid maintainable code. Most teams ended up with a healthy mixture of the two, which worked great.

I once ran into a hiring manager that only wanted to hire people like himself, with the same skills and philosophy. I tried explaining why we needed people with a more diverse set of skills and strengths, but he wouldn't bulge. Unsurprisingly his team didn't deliver much value to the company.

My first job was on working on drivers for a proprietary OS. Every time a new board came out, the protocol was to copy the code for the most similar board and start making modifications. It works, but there's a whole lot of repeated logic for common init sequences and logical mapping of memory addresses to what they control. The "simulator" that was widely praised for cutting down on spin-up time for a new board was nothing more than stub code. It all worked and was maintainable, but everything was harder than it needed to be.

This is almost a word-for-word description of the dev workflow for a proprietary embedded OS I worked on as an intern. Even the "simulator" was what you describe - some #ifdefs that turn the program into a cli program using Win32.

This worked for us because our approach was to "make it right the first time, update only when necessary."

> Every time a new board came out, the protocol was to copy the code for the most similar board and start making modifications

I only saw that happen at one place. It was a bit of a shitshow.

Big corps don't do that, they have a clear internal division between various levels of hardware-independent and hardware-specific components, down to workarounds for specific bugs in specific releases.

It's a weird field in that regard. I'm a CompE, but I started college as an EE and switched pretty late. My skillset is more closely aligned with the CS folks, but my formal education and training was by EEs, for EEs. I still do "hardware stuff" for fun.

The best firmware teams I've worked on have always had a mix of disciplines. Heck, I mentored a mechanical engineer for a while (he became a very good firmware dev). You have to have good programmers who manage to write modular, maintainable code even if the language and hardware limitations fight them the whole way. You need folks who understand Electrical Engineer-speak. Depending what you're doing, you might HDL people, and that stuff might as well be a completely separate discipline from regular software. You need people who are comfortable debugging with nothing more than log messages, and if you're lucky, a coredump. You need a manager who can wrangle the occasional "it's a hardware problem" vs "it's a firmware problem" debate.

Yep, that matches my experience. There was a lot of Feynman debugging as well. It's a good job for somebody who is eager to learn new stuff and get out of their comfort zone. Another great thing about it is that people tend to stick around for a long time, so you build good friendly relationships with your coworkers.

The biggest downside of driver development is that it becomes very repetitive after a while: you are the maintainer of this immense complex piece of clockwork (the hardware) that you must to keep ticking reliably at all times by working around all the bugs in it. It sometimes feels like your beautifully crafted software contains as much code to track and work around hardware bugs as it contains code fof the idealized hardware described in the origibal documentation.

It's not completely meaningless but it does tend to be something people recite and then never think about - even when they're inadvertently following it. It's performative - a bit like reciting the bible.

Take I as an example - "don't depend upon interfaces which you do not use". I've seen good developers cut out dependencies hundreds of times for this reason - not because they've trained themselves on SOLID but because it just feels right after years of experience. If I said "this is part of SOLID" many of them would go "... is it?" "hmmm. I guess it is..."

As with reciting the bible, just because somebody recites it doesn't mean that they took it to heart and people who take it to heart can't necessarily recite it.

Being able to recite it is just a ritual used as a social signaling mechanism. It's a bit like leetcode, an ability to recite big O notation or knowledge of git's internals - symbols of "developerness" that don't necessarily align with skill.

Reply on news.ycombinator.com