Becoming a Good Engineer | Hacker News Reader

Becoming a Good Engineer

0x0001.cc

16 pointsmadmax1088 comments

I really like the point about reading books. I often notice that some engineers miss a lot by preferring videos and shallow posts over documentation and books.

Also, it strikes me how often people would rather ask a question on something trivial rather than read the docs or at least Google the question.

Being able to search for information is such a crucial skill

> Also, it strikes me how often people would rather ask a question on something trivial rather than read the docs or at least Google the question.

This is in my opinion one of the easiest pitfalls of modern enterprise software development. Too often I catch myself asking people questions that I could quite easily find the answer to myself. This both devalues documentation, since it won't be used anyway, and wastes the time of the people I ask.

One of my greatest points of self improvement has been to catch myself and look at the documentation first. Then if I really can't figure ot out. Turn the question into a question that can be answered by improving the documentation.

I'm nowhere near perfect at it, in a moment of weakness I still ask questions I shouldn't have asked, but I'm proud of how often I stop myself.

Yeah, the problem with in house frameworks and other such custom code that I face is that the people who wrote it are long gone, the documentation is scattered and many times out of date of the actual code and the code itself is kinda convoluted with little to no comments explaining it. I feel like if LLM's are properly trained on company code and the in house documentation data then this could be a big boon, so that instead of having to search for documents on company cloud drives and chat threads etc, you can just ask the chat AI and it will surface the relevant data to you faster than you could find it yourself.

I work with young developers (twenty-somethings) that really don't like going through the books and documentation when dealing with something new. They much rather go hands-on from the getgo and deal with doubts as they arise.

They're pretty fast like that and I admire the hacker spirit. But I think they miss important nuance that a proper training (even self-) would give them.

I agree with a lot of the points mentioned in this article. But one thing I'm not sure of is how does knowing the deep underlying fundamentals of CPU, memory, http etc . Help you be a better engineer, cause most engineers just work at a very high levels of abstraction and the languages and framerorks used at that level don't allow low level access for memory etc anyway. I mean you should not be clueless about these basic things buy I don't understand the day to day application of it, outside of academia.

I think it all boils down to a certain degree of mechanical sympathy:

https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-2...

Based on my understanding, this is similar to how commercial pilots are trained. They are nowhere near the level of understanding to build or repair aircraft systems, but they need to understand the basics of systems to make informed decisions and have the "mechanical sympathy" not to be clueless when operating the aircraft.

At least, that's how I motivate myself to learn more about low-level stuff while setting up CRUD endpoints at work.

Thank-you. This led me to Staged Event-Driven Architcture (SEDA) [1] (via Stack Overflow [2]) and actors.

[1] https://web.archive.org/web/20160811044810/http://www.eecs.h...

[2] https://stackoverflow.com/a/8129064

I guess that makes sense if you are building something that needs a high degree of efficiency or sits closer to the metal, but most of the day-to-day tasks in corporate work aren't really in need of this level of mechanical sympathy, you can implement a slightly unoptimized logic and still have the system perform at an acceptable level, the bigger causes of latency will likely be IO like DB access anyway. And the bigger challenge when working on these tasks are the people problems, where you have to work with others who give vague requirements that they then keep changing after the work has already started while still holding you to the fixed deadlines, I wouldn't waste time writing the most elegant and per formant code in this scenario because it won't be appreciated by anyone and will lead to penalty for delays for me.

Reply on news.ycombinator.com