6 ms·

Think Twice, Code Once

37 points by brunokiafuka 2y ago

deleted 2y ago
[deleted]
davidhyde 2y ago
> "When I review code from more junior developers or even tenured developers, I find a tendency to either overengineer or overcomplicate solutions" The article then launches into recommendations about requirements gathering and writing down your thoughts (functional specs anyone?) which kind-of sounds a little bit like the waterfall method to me. I believe the waterfall method has a bad reputation for overengineered and overcomplicated solutions. We have come full circle, again! No matter the methodology there seems to be this behavior in the industry that as soon as some code does the job, regardless of how terrible it is, it must not be touched again and we must move on. Whether it was over-engineered because of bloated requirements gathering or because it was hacked into some sprint period the end result is the same. My recommendation is this: Don't discourage people from refactoring code that already works. Good code will survive refactoring or even rewrites.
- brunokiafuka 2y ago
  I agree with your point that code should be refactored. The main idea of the article is to encourage developers to take some time to think before writing code. Even if you have the functional specifications for a feature, you might not have a clear idea of how to implement it. Taking some time to think and plan your approach can not only improve your initial implementation, but also simplify the process of refactoring later on.
- RaftPeople 2y ago
  > The article then launches into recommendations about requirements gathering and writing down your thoughts (functional specs anyone?) which kind-of sounds a little bit like the waterfall method to me. I believe the waterfall method has a bad reputation for overengineered and overcomplicated solutions. We have come full circle, again! That's not really waterfall, it's just normal analysis and design. The trick is to identify when you have enough domain knowledge that the analysis and design time is valuable/optimal, or to identify that you don't have enough domain knowledge and need to iterate to gain the knowledge.
spyspy 2y ago
> When I review code from more junior developers or even tenured developers, I find a tendency to either overengineer or overcomplicate solutions This has been the biggest struggle of my career. No one ever wants to take the easy route. Everyone thinks they are smarter than everyone else. Everyone thinks their little API is going to be globally popular and needs triple redundant failover zones, 64TB of memory, Kubernetes, scale, scale, scale.
- piloto_ciego 2y ago
  Not me! I want to write the dumbest most maintainable code possible. I want to use the most maintainable hardware, and the least complicated toolchain available. Now, please excuse me while I practice leetcode for my first job out of grad school where if I cannot regurgitate a complex algorithm (which is available in a well maintained library that I should never try to reproduce) I’m an unemployable dumbass.
  - quectophoton 2y ago
    Decade-plus-something web dev experience here. I'm still an unemployable dumbass. Been applying to both backend and frontend positions, and to me the market looks like that "fronthand backhand" Key & Peele sketch (just mentally replace with "frontend backend"). I'm only surviving so far because someone I know offered me freelance work, but it probably won't last too long, and nobody else I know is hiring for a remote (or nearby) position. Maybe, if I lived in either of the 2 cities where 90% of the on-site developer job positions are located, maybe, things would be a bit easier.
    - mock-possum 2y ago
      I wouldn’t take it personally if I were you, the employment situation suuuuuuuuuuucks right now, worse than it’s ever been. Five years ago you’d have had a much easier time.
      - IshKebab 2y ago
nemetroid 2y ago
Anything worth coding is worth coding at least twice. Do spend some time thinking about the problem before getting into it, but writing the code is often the quickest way to understand which design questions you need to ask yourself. Just don't be afraid to throw away your code. It helps to be quick at typing. It's common to hear "typing speed doesn't matter, I spend much more time thinking than typing", but I find that colleagues who are slow typers are more eager to push on with the first (flawed) attempt.
- wilkystyle 2y ago
  This is so hard to do well, especially when under all of the usual business pressures, but I 100% agree with you about the understanding gained from pushing quickly to hands-on implementation. Just anecdotally, I have historically done my absolute best work when it is my second attempt at implementing it. As always, there is definitely a balance, and I definitely do not want to downplay the importance of critical thinking. You would not do well climbing Mt. Everest by simply starting the climb with the intent of figuring it out and adapting along the way, but you also won't be any good at basketball if you spend all your time reading books and watching videos without stepping onto the court and trying it out. In my experience, there are two key things that determine whether or not I am successful at this: 1. To develop the ability to rapidly prototype something that is representative of the thing I ultimately want to build, without falling into the trap of all of the optimizations and rigor applicable to the final product I will ultimately deliver. 2. The ability to commit to throwing something away that I have invested time, effort, and learning labor in. At every step of the way, I find myself attached to the thing I'm building, and thus wanting to keep it around and apply all of the optimizations that violate point 1 above.
  - appplication 2y ago
    As much as I love TDD, it really makes your last point so much more difficult. TDD feels like “do it nice or do it twice”, when you’re describing a more iterative approach. Of course they’re not strictly exclusive of each other, but maybe feel like slightly opposite paradigms in practice.
- 2y ago
kugurerdem 2y ago
Nice essay. I too like to write and rethink before starting implementation stuff. I think one issue here is that it is very hard to predict domain-specific problems until you encounter them. If you're working in a domain you are already experienced in, a top-down approach will likely work fine. However, if you are attempting something new, you're bound to run into unforeseeable implementation problems. This is why I believe improving your skills related to iteration speed is just as important as planning. People often think that the top-down approach is just better than the bottom-up approach, but I think there are lots of cases where the bottom-up approach is just as important as the top-down approach. See the "Top Down versus Bottum Up" section from The Art of UNIX Programming book. [1] [1]: https://www.arp242.net/the-art-of-unix-programming/#id2899552 https://www.arp242.net/the-art-of-unix-programming/#id289955...
m0llusk 2y ago
Then code again. Iteration!
sgbeal 2y ago
> I ran through the same issue for so long until I heard a quote that said — “think twice, code once”, — and I incorporated it into my process Conversely, Bob Dylan has, for many years, been telling us, "don't think twice, it's alright."
Terr_ 2y ago
I'd go more for "write one to throw away." The writing process itself is an important way of thinking things out, especially when there are too many details and possible confounding factors.
hulitu 2y ago
> Think Twice, Code Once This was a long time ago when computer time was expensive. Now is: don't think, code it, ship it, see if someone complains. (Google, Microsoft and others).
sneed_chucker 2y ago
Code as many times as you want, but if your prototype goes into production it will be annoying to fix mistakes in a clean way.
- flysand7 2y ago
  Can relate to this one though, when you push the code in production, pushing more changes just comes with so much more additional worries: Will it interrupt user's work on a live system, what about refactoring, changing API's that can break things. There's a fear that whatever you push next could break things really hard so you end up giving up the code cleanliness in exchange for mental rest.

37 points by brunokiafuka 2y ago

deleted 2y ago

[deleted]

> "When I review code from more junior developers or even tenured developers, I find a tendency to either overengineer or overcomplicate solutions" The article then launches into recommendations about requirements gathering and writing down your thoughts (functional specs anyone?) which kind-of sounds a little bit like the waterfall method to me. I believe the waterfall method has a bad reputation for overengineered and overcomplicated solutions. We have come full circle, again! No matter the methodology there seems to be this behavior in the industry that as soon as some code does the job, regardless of how terrible it is, it must not be touched again and we must move on. Whether it was over-engineered because of bloated requirements gathering or because it was hacked into some sprint period the end result is the same. My recommendation is this: Don't discourage people from refactoring code that already works. Good code will survive refactoring or even rewrites.

brunokiafuka 2y ago
I agree with your point that code should be refactored. The main idea of the article is to encourage developers to take some time to think before writing code. Even if you have the functional specifications for a feature, you might not have a clear idea of how to implement it. Taking some time to think and plan your approach can not only improve your initial implementation, but also simplify the process of refactoring later on.
RaftPeople 2y ago
> The article then launches into recommendations about requirements gathering and writing down your thoughts (functional specs anyone?) which kind-of sounds a little bit like the waterfall method to me. I believe the waterfall method has a bad reputation for overengineered and overcomplicated solutions. We have come full circle, again! That's not really waterfall, it's just normal analysis and design. The trick is to identify when you have enough domain knowledge that the analysis and design time is valuable/optimal, or to identify that you don't have enough domain knowledge and need to iterate to gain the knowledge.

spyspy 2y ago

> When I review code from more junior developers or even tenured developers, I find a tendency to either overengineer or overcomplicate solutions This has been the biggest struggle of my career. No one ever wants to take the easy route. Everyone thinks they are smarter than everyone else. Everyone thinks their little API is going to be globally popular and needs triple redundant failover zones, 64TB of memory, Kubernetes, scale, scale, scale.

piloto_ciego 2y ago
Not me! I want to write the dumbest most maintainable code possible. I want to use the most maintainable hardware, and the least complicated toolchain available. Now, please excuse me while I practice leetcode for my first job out of grad school where if I cannot regurgitate a complex algorithm (which is available in a well maintained library that I should never try to reproduce) I’m an unemployable dumbass.
- quectophoton 2y ago
  Decade-plus-something web dev experience here. I'm still an unemployable dumbass. Been applying to both backend and frontend positions, and to me the market looks like that "fronthand backhand" Key & Peele sketch (just mentally replace with "frontend backend"). I'm only surviving so far because someone I know offered me freelance work, but it probably won't last too long, and nobody else I know is hiring for a remote (or nearby) position. Maybe, if I lived in either of the 2 cities where 90% of the on-site developer job positions are located, maybe, things would be a bit easier.
  - mock-possum 2y ago
    I wouldn’t take it personally if I were you, the employment situation suuuuuuuuuuucks right now, worse than it’s ever been. Five years ago you’d have had a much easier time.
    - IshKebab 2y ago

nemetroid 2y ago

Anything worth coding is worth coding at least twice. Do spend some time thinking about the problem before getting into it, but writing the code is often the quickest way to understand which design questions you need to ask yourself. Just don't be afraid to throw away your code. It helps to be quick at typing. It's common to hear "typing speed doesn't matter, I spend much more time thinking than typing", but I find that colleagues who are slow typers are more eager to push on with the first (flawed) attempt.

wilkystyle 2y ago
This is so hard to do well, especially when under all of the usual business pressures, but I 100% agree with you about the understanding gained from pushing quickly to hands-on implementation. Just anecdotally, I have historically done my absolute best work when it is my second attempt at implementing it. As always, there is definitely a balance, and I definitely do not want to downplay the importance of critical thinking. You would not do well climbing Mt. Everest by simply starting the climb with the intent of figuring it out and adapting along the way, but you also won't be any good at basketball if you spend all your time reading books and watching videos without stepping onto the court and trying it out. In my experience, there are two key things that determine whether or not I am successful at this: 1. To develop the ability to rapidly prototype something that is representative of the thing I ultimately want to build, without falling into the trap of all of the optimizations and rigor applicable to the final product I will ultimately deliver. 2. The ability to commit to throwing something away that I have invested time, effort, and learning labor in. At every step of the way, I find myself attached to the thing I'm building, and thus wanting to keep it around and apply all of the optimizations that violate point 1 above.
- appplication 2y ago
  As much as I love TDD, it really makes your last point so much more difficult. TDD feels like “do it nice or do it twice”, when you’re describing a more iterative approach. Of course they’re not strictly exclusive of each other, but maybe feel like slightly opposite paradigms in practice.
2y ago

kugurerdem 2y ago

Nice essay. I too like to write and rethink before starting implementation stuff. I think one issue here is that it is very hard to predict domain-specific problems until you encounter them. If you're working in a domain you are already experienced in, a top-down approach will likely work fine. However, if you are attempting something new, you're bound to run into unforeseeable implementation problems. This is why I believe improving your skills related to iteration speed is just as important as planning. People often think that the top-down approach is just better than the bottom-up approach, but I think there are lots of cases where the bottom-up approach is just as important as the top-down approach. See the "Top Down versus Bottum Up" section from The Art of UNIX Programming book. [1] [1]: https://www.arp242.net/the-art-of-unix-programming/#id2899552 https://www.arp242.net/the-art-of-unix-programming/#id289955...

m0llusk 2y ago

Then code again. Iteration!

sgbeal 2y ago

> I ran through the same issue for so long until I heard a quote that said — “think twice, code once”, — and I incorporated it into my process Conversely, Bob Dylan has, for many years, been telling us, "don't think twice, it's alright."

Terr_ 2y ago

I'd go more for "write one to throw away." The writing process itself is an important way of thinking things out, especially when there are too many details and possible confounding factors.

hulitu 2y ago

> Think Twice, Code Once This was a long time ago when computer time was expensive. Now is: don't think, code it, ship it, see if someone complains. (Google, Microsoft and others).

sneed_chucker 2y ago

Code as many times as you want, but if your prototype goes into production it will be annoying to fix mistakes in a clean way.

flysand7 2y ago
Can relate to this one though, when you push the code in production, pushing more changes just comes with so much more additional worries: Will it interrupt user's work on a live system, what about refactoring, changing API's that can break things. There's a fear that whatever you push next could break things really hard so you end up giving up the code cleanliness in exchange for mental rest.