I prefer an alternate measure - great developers write code with a long half life relative to the rest of the product. (An idea I learned from a hiring reference check ... of all places.)
The Best Engineers Write Less Code
21–30 of 31 posts
Re: The Best Engineers Write Less Code
#22The "go delete some code" link goes to a 404 page, which is quite fitting :D wonder if it was on purpose...
Links are broken--proper ones below. They all have a similar tone/structure, like it had a few seeds of originality but then got 'produced'. More style than substance/depth for my liking. [0] https://shvetsm.github.io/posts/who-looks-at-the-code/ [1] https://shvetsm.github.io/posts/keep-the-kitchen-clean/
links have been fixed, thx
Re: The Best Engineers Write Less Code
#23"One of my most productive days was throwing away 1000 lines of code" - Ken Thompson
Re: The Best Engineers Write Less Code
#24Many people try to design a perfect system on the first attempt. And for the original requirements, it often works beautifully. But as new requirements appear, the clean design slowly turns into layers of patches and exceptions. you discover a deeper pattern that absorbs the complexity back into the core, and you do a rewrite. Then the cycle repeats. I don't worry about writing a perfect system anymore, i realize the…
As a counterargument. Making the wrong architectural decision can lock you in a design that's horrible. And once people start building on top of it you are forever stuck with it (or at least it will require a monumental effort to change it)
Re: The Best Engineers Write Less Code
#25One big difference I see in how minds work is their ability to model. A few people I know focus on end-to-end model thinking — trying to maximize against some functions. The rest of them seem to avoid thinking outside a small info bubble/closed system, not sure why, but it looks like it creates anxiety when they start feeding too much info. Instead of trying to extract abstractions that make it possible to model the…
When I was reasonably experienced, and about 6 months into a new job, one of my co-workers, Fred, had been there for a very long time.
Fred was very knowledgeable, and Fred could think. But Fred had deeply held preconceived notions that interfered with the utility of his thoughts.
Fred also had something else, though -- he could set aside those deeply preconceived notions. Not for himself, mind you, but for someone else.
I could, and did on a very regular basis, go to Fred and say "Fred! Assume X, Y, and Z. What happens if A and B?" Now even though Fred was completely sure that I was wrong about at least Y and Z, he could set aside those prejudices, and (correctly!) reason through what would happen.
Fred reminds me of the people you describe, except that instead of having Fred's code running through my brain, I was able to insert my code into Fred's brain.
Re: The Best Engineers Write Less Code
#26Coding used to be bottlenecked by typing speed; now, it’s bottlenecked by our ability to comprehend and maintain.
Not my experience at all (30+ years of getting paid to deliver software).
Thinking hard (and discussing with experienced colleagues) before writing any code can dramatically speed up your overall delivery time and completely remove whole classes of potential errors.
If you skip the "thinking hard" bit to "go fast" you will probably end up being 10x slower overall.
Re: The Best Engineers Write Less Code
#27>The Best Engineers Write Less Code
That's because they are designing circuits. EE FTW!
Re: The Best Engineers Write Less Code
#28One big difference I see in how minds work is their ability to model. A few people I know focus on end-to-end model thinking — trying to maximize against some functions. The rest of them seem to avoid thinking outside a small info bubble/closed system, not sure why, but it looks like it creates anxiety when they start feeding too much info. Instead of trying to extract abstractions that make it possible to model the…
There has to be some language for what you're describing, because I've experienced similar perceptions of people. I've been on both sides of the "you don't actually understand what is being said until years later" discussions as well.
One thing I'd posit is that it might not be the people, but rather an ability or skill people can improve. It takes difficulty and focus and time, but it can be honed. I know this to be true; otherwise I would not be able to understand that which I dismissed years ago!
The problem with this, if it is an active ability rather than a person's inherent traits, is that it becomes impossible to recognize by any identifiable markers. I've often found that some of the most intelligent and "look at the problem from all angles" kind of minds often have very glaring blind spots (look no further than political subjects, for example). These blind spots manifest even in the most generally intelligent thinkers, that's what makes people human after all. So it can be said that good thinking is a very delicate thing, and it can be difficult to recognize against noise no matter who is speaking or what they are discussing.
Re: The Best Engineers Write Less Code
#29I prefer an alternate measure - great developers write code with a long half life relative to the rest of the product. (An idea I learned from a hiring reference check ... of all places.)
This is in all likelihood an improvement on just measuring lines of code output, but not at all a silver bullet. I'd imagine this skews heavily towards developers who were around first in large projects. Also skews towards developers who pick certain tasks over others - there's always circumstances where the library you are building on passes breaking changes, etc. but that I feel might be more minor in comparison to the first concern.
Re: The Best Engineers Write Less Code
#30There's also the sunk cost fallacy. Instead of removing code/features that it's becoming more and more obvious were a bad idea to begin with they get kept in the code base causing even more problems and delays because of "we cannot just remove it after spending so much time and money creating it".
The issues with bad code/architecture/complexity often gets "solved" by creating even more of it.