_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Think Twice, Code Once
Terr_ wrote 13 hours 53 min 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.
sgbeal wrote 15 hours 51 min 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."
m0llusk wrote 15 hours 54 min ago:
Then code again. Iteration!
kugurerdem wrote 18 hours 20 min 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]:
URI [1]: https://www.arp242.net/the-art-of-unix-programming/#id2899552
nemetroid wrote 21 hours 32 min 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.
apantel wrote 17 hours 25 min ago:
I agree. The first time you try to make a new type of thing, it
takes a lot of trial and error to understand the domain and get
things working. But once youâve done that and understood the
domain, you can usually do much much better with a second greenfield
attempt, completely from scratch.
wilkystyle wrote 17 hours 50 min 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 wrote 3 hours 46 min 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.
spyspy wrote 1 day 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 wrote 1 day 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 wrote 21 hours 12 min 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.
piloto_ciego wrote 9 hours 22 min ago:
This is more evidence to me that Iâm fucked. Honestly, I think
I need to probably just do my own thing here when I get done
because if I donât, well, relying on someone to take a chance
on a 36 year old dude with a family and other obligations seems
like a losing propositionâ¦.
mock-possum wrote 15 hours 8 min 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 wrote 2 hours 33 min ago:
Presumably this is just for some locations/domains? I still get
a mountain of recruiter spam...
davidhyde wrote 1 day 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.
RaftPeople wrote 16 hours 52 min 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.
brunokiafuka wrote 1 day 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.
DIR <- back to front page