Comment by klipo | Hacker News Reader

Comment by klipo | Hacker News Reader

Good luck! I’m going through a similar journey. I’m in my late thirties and only started software engineering professionally 5 years ago, without a formal CS degree, but with a hobby-level affinity for computers. It seems like you have an intrinsic interest in the subject. I think this is THE key, because you will grow the most by figuring things out in a play-like fashion, this will solidify your understanding and build intuition.

Looking back what has helped me a lot is being surrounded by more experienced engineers that were good at teaching (those are quite rare I discovered later). Other than that, read a lot of code, write a lot of code, and keep reflecting on what areas to further develop. Be kind to yourself, this space is huge and no one’s is an expert in all of it. Burn out is real, especially when struggling alone for too long. One thing that has helped me as well is to realise everything in software engineering has been made by humans. None of it is actually ‘unknown magic’, just keep digging deeper to find out how the thing you’re struggling with works on a more fundamental level. The LLM age has made this so much easier.

I don't know how comfortable I feel throwing around terms like computer science and software engineering. I know a lot of people who can program but I would never have them design a medical system or anything having to do with life or death situations.

the keyword there is "design". systems engineers/architects design those things, not coders. And they are made safe by entire teams of academics, clinicians, engineers, testers, scientists, and even lawyers.

I would argue that even if other people have designed an entire system and "all" that is left to do is to write the code, things can go very wrong if the coder isn't good at designing their code well (e.g. to be efficient, robust, etc.). It's "design" all the way down; there is no imaginary line where design stops and coding starts.

thats true, if there were one sigle "coder" who was cloistered away from the team and came back when s/he claimed the requirements were met and the task was complete. Whereas, in FDA (and presumably FAA/DoD) regulated designs, a massive team is following a rigid SDLC including code reviews for best practices.

Now, technically the FDA doesn't force that, all they specify is that some standard procedure must be followed, and written evidence must be produced upon demand showing that the procedure is followed. So you could contrive an example where a cowboy coder made his own sqrt() and completely broke it, and that somehow led to the death or injury to a patient, or an elevator going into free-fall. or a fuze detonating. sure. Is that likely to happen? absolutely not.

> a massive team is following a rigid SDLC including code reviews for best practices

Regardless of how thoroughly a system is planned in advance, programmers are not automatons who mindlessly fill in the last few blanks. They must make choices about the code they write, and that is absolutely a part of the overall design. If that code fails a code review, well, then it gets rewritten, but that's ancillary to my point: programming is design (albeit at a lower level than the overall system design).

> just keep digging deeper to find out how the thing you’re struggling with works on a more fundamental level.

Thank you. I will keep these in mind.

Your journey is a source of motivation as well.

Reply on news.ycombinator.com