101–110 of 174 posts
Great software engineers know not to create PDFs when HTML works fine.
Given that it is presumably part of a journal, I am not sure that HTML would have worked fine. The purpose was to publish in one of those. We are a secondary audience.
Earlier quoted context omitted.
Hm, I don't know where you got this idea from... I certainly didn't mean it like that.
Then write down what you mean, people aren't mind readers. However you will find it quite hard to write down what you mean in this case since your statement doesn't work even if you talk about other situations. Like should you hire a guy to manually set a field in new entries in the database every night instead of writing a short script to do it for you? That is a non code solution, so your answer would be yes. But I…
A good engineer stops unrealistic/bad ideas before they even reach a point where people start to think about how the idea could be carried out in detail.
In 50 years of programming I've worked with a few. One characteristic is a deep understanding and command of all that they touch. For example, I worked with Bill Schelter (GNU Common Lisp). In 1980, prior to the Internet, we were working on a problem (tail recursion). He was using the emacs editor and he found a bug. Bill stopped what he was doing, fetched the sources for emacs (using ftp), found the source of the bu…
I encounter so many bugs nowadays in my tools. I would probably spend all my time fixing those bugs in multi-million-LoC codebases (assuming that tool is open source). That story sounds like something that could happen back in the day, when things were simple enough. I wonder if it could happen today.
I found this amusing but not necessarily wrong.
In 50 years of programming I've worked with a few. One characteristic is a deep understanding and command of all that they touch. For example, I worked with Bill Schelter (GNU Common Lisp). In 1980, prior to the Internet, we were working on a problem (tail recursion). He was using the emacs editor and he found a bug. Bill stopped what he was doing, fetched the sources for emacs (using ftp), found the source of the bu…
In your example, this Emacs bug fixing, there is a lot of people who work hard but would just think that the bug is probably difficult to fix (they would fear of it taking too long to do) and decide not to do it.
I know personally how much anxiety can block you from doing things that help you progress. It also makes decision-making slower. I think playfulness can help to alleviate it, but it's hard to maintain in a "professional" setting.
I think if you follow John Carmack's finger files and his Twitter account you can form your own opinion as to how it works. That guy is clearly a top 10 engineer and he hides little about his thought process. His appearance on the Joe Rogan Experience was great too.
As an aside, in his appearance on JRE, there's one part where Joe Rogan asks him about working hard and JC says something like (going off memory) "I don't really like that idea - of working really hard being the thing. Personally, I've noticed that after a while the quality of my work really drops off. Around 13 hours in I'm not really doing a good job". I remember the moment because I was listening to this while dri…
Often it simply takes some time for solutions to new problems to percolate, and you need to take a step back regularly during the process. Forget about the problem completely and do something completely different, interspersed with short bursts of research and reading on related topics. Sooner or later the contours of a solution will start to form and you will (hopefully) be able to realize it much quicker and at higher quality compared to 'working hard' by pounding yourself and trying to force things.
I cannot count the number of times I almost gave up on a problem after working myself into multiple dead-ends, and almost instantly seeing a path forward after taking a few steps back and allowing my brain to work itself out of these dead-ends.
Not spending 1 week of 'hard work' on a bad solution can save you months of work in the future.
Great software engineers create/build software only as a last resort, once all other options have been exhausted. :)
No they don't, writing new code is often cleaner and simpler than adding a library. Exactly when to do either is arguable, and picking the right choice requires skill. So always going the library route when possible means you aren't a great software engineer.
Adding to the ball of mud is often the easiest but not the best option.
It’s interesting there are so many different answers given to this question whenever it is asked. If we asked, “What makes a good surgeon?” or as pointed out in another comment, “What makes for a great basketball player?” it seems that there would be less debate. It seems to me that this debate is related to another question, “Why do so many software projects fail when you don’t see any skyscrapers collapsing under t…
I think this is a great question to use as a thought exercise. We don't see the designs that fail, as they don't pass the review? Using the analogy of software engineering being the design stage (vs build/construction stage), this would be a closer comparison. How many skyscraper designs fail before they end up being "uptaken".
Also, just because buildings don't collapse and fail catastrophically, I assume there are many flaws in the design that get "worked around" during construction. Many flaws (bugs) do likely end up "in production", but they are more of a technical debt type of issue that will be a burden for building maintenance and/or future tenants.