
Programming: Doing it more vs. doing it better - lonesword
https://kevinmartinjose.com/2019/04/08/programming-doing-it-more-vs-doing-it-better/
======
kragen
Someone who's been programming for three years is still a beginner, even
though based on what he wrote here, Kevin is almost certainly a lot better
than I was when I'd been programming for only three years.

I do find that a lot of programming stuff that used to be hard is easier for
me now that I've been progrmaming for 38 years. But that doesn't mean I spend
all my time doing things I can do without thinking, and it certainly doesn't
mean I write code that doesn't need refactoring. Maybe my designs are better
than they used to be — I think so — but often that's because I developed the
design _more_ incrementally through refactoring, rather than _less_
incrementally by planning.

I do avoid a lot of errors by thinking through the consequences of a choice
before taking action, in a way that I couldn't always do. But often that
choice is specifically the choice to plan out a big design at the start of a
project.

Also, though, what counts as "big" has changed for me. What I can hack
together in an afternoon now might have taken me a week ten or fifteen years
ago. So I can explore alternatives with less risk, in a way.

The author describes a lot of anxiety and guilt about doing things
imperfectly. I think that's a big obstacle to improvement — other people can
pick up on that and will be reluctant to give you feedback, and feedback from
other people is a really fast way to improve. Also, it tends to shunt you into
tasks that don't challenge you enough — it pushes you to avoid risk, and
pushes other people to not ask you to do things that are at the limit of your
abilities. This is precisely the dynamic Atwood was trying to combat by
telling his story.

~~~
segmondy
Someone programming for 3 yrs is not a beginner, There are people programming
at 3 yrs that are experts and will run circles around you and your 38 years.
Some people really have the talent and put in the work to get good. In 2019,
the mentorship is available via means of books, blogs, MOOC, youtube videos,
conferences. What some folks can achieve in 3 yrs these days is really
unbelievable. P/S, I have been hacking around the computer for 25yrs and think
I'm a pretty good programmer too. But I have been impressed by some 2 yrs old
& 3 yrs old experiences.

~~~
hhs
Interesting view. I'm learning, with about 8 months worth of knowledge and
experience, and this is useful.

Did you notice any skills/traits in those people who were "unbelievable" in
those 3 years? For instance, did they do "test driven development"? Also, did
they keep good log habits?

~~~
pm90
I think OP has provided good context. But I will try to answer the question
you _really_ seem to be asking: unfortunately there is no shortcut.

There are things you can do that will, like the author said, give you faster
feedback and thus let you get better _if_ you use that feedback. You might
write a lot of code and read a lot of code and internalize good patterns.
Eventually you will have enough experience and the confidence that comes with
it, to take on bigger and bigger challenges. I don’t know what happens after
that for I am still in that stage. But I have observed more experienced
programmers and one thing they’re very god at is _really reading_ others’ code
thoroughly and being able to spot better ways of doing things (which I imagine
is through experience) and also thinking a little bit in the future rather
than simply the assigned task. e.g. if assigned to create a new system, they
won’t just follow the design specs blindly, but will question the design
choices rigorously, helping improve the design a lot, and then implement
something a tiny bit better than the eventual design.

Maybe I’m making it a bigger deal than it is, but I’ve worked closely with
senior engineers and it’s _always_ a fascinating experience. They will
question your design and code very very deeply but all of them will be good
questions and will help you either improve your design or not add spurious
code.

~~~
hhs
This is very helpful. Your points make me think of the need for immersing in
the experience and intently considering not only the 'what' but also the 'why'
of actions, as well as alternative approaches to solve problems.

It also makes me think of the importance of stepping back, questioning the
scope of "design choices" available, and anticipating things other "than
simply the assigned task", possibly for some long-term aim, as you write. This
is neat, thanks.

------
sinuhe69
I think one word would shed light on such anecdotes: deliberate practice.
Countless literature and researches have pointed out that simply doing more
would not bring much improvement but find out what is missing and practice it
to perfection then move to another weaknesses is the best way to achieve top
performance, be it in sport, in music or other fields. Like someone who want
to learn chess; simply plays a lot each and every day will improve his ELO
slowly but it will stall after a while (say at the level of a club player) and
he can almost certainly never attain the mastery. In opposite, someone who
seeks guidance, study and practice to fix his weaknesses and perfect his
technique will improve vastly more in the same amount of time. Effective
practice and coaching is also the only difference between merely very good
players and grand masters. I can’t imagine why it should be different in the
field of programming and software engineering. Someone who writes thousands
sloppy games might have learned how to do them faster (and maybe better) but
he still learned nothing more about complex systems or secure systems. Only
with intense study and practice he can master such stuffs effectively.

The Talent Code of Coyle is a good book to start reading about deliberate
practice.

~~~
tekkk
Yes, exactly this. If you never really think about your coding seriously, and
ponder where you should get better at and then do it - you'll never improve!
Simply by acknowledging your own mistakes and how you could fix them in the
future, let's you build up skill much better than just churning out code day
in day out without giving it a second thought.

I've seen the both extremes, the programmers who are so serious about the
style of the code that nothing really satisfies them (and consequently
progress happens at snail's pace). Then I've seen those, who'll write the
ugliest of hacks just to get the thing working and move on. I think there's a
deliberate balance between the two, where you feel you're not wasting time on
useless things but actually get something done, which you can then comfortably
show to your peers without beginning to blush.

And only way of getting there is practise and being mindful of what you are
doing. Similar to sports, music - whatever. To know where and how you did
wrong is key, often you'll need a very good teacher to show you that.
Criticizing yourself works too, but often you either become too strict to
yourself or too lenient.

Just starting to code without worrying if this is the "best practise" or not
will allow you get into a flow which is much better than over-thinking your
approach. Because once you start to do it, like a good warm-up it allows you
to see the problem much clearer as you become aware of the problems as you
encounter them. Then if you have time, you might want to refactor your
solution or just move on the next most important thing. Sometimes it's better
to just write awful code to get to that MVP or other important milestone, only
after which you start to review your code. Experience will tell you, when is
the right time to move fast and when it's good to slow down and enforce a
particular paradigm to your codebase.

------
jondubois
I've been coding intensively for more than half of my life from a young age -
I'm approaching 16 years of experience now. Also, I've been doing it quite
intensively (I was writing games when I was still in school before studying
software engineering at university, then I worked for 14 different companies;
some startups and some corporations in about 10 different industries. I've
completed projects in at least 7 different programming languages). Also I've
always been working on a side project during nights and weekends; mostly open
source.

I have mixed feelings about the ceramics anecdote because I've met some people
who have been coding a long time and producing large quanities of code but
it's not good quality. To write high quality code, you need to enjoy the
process and be adaptable. You need to have been exposed to a lot of different
kinds of projects and management cultures.

Also, the most frustrating thing is that other people who are not good coders
don't recognize straight away who is a good coder. Often, it takes a whole
year to prove yourself. However, good coders usually know straight away who a
good coder is.

Because of this effect, our industry is currently in a bad state. Many of the
big popular tech stacks are mediocre compared to some of the alternatives that
are available. There is a lot of misinformation and misplaced hype.

Most people who have the power to make hiring decisions are not sufficiently
good at coding to be making those decisions. So good coders tend to find
themselves smothered in most work environments...

~~~
passivepinetree
Can you elaborate on your opinions about frameworks? What are some tech stacks
that are mediocre, and why are they mediocre? What makes an alternative
better?

------
lifeisstillgood
Please stop thinking there are 10x programmers - or perhaps stop thinking it
means 10x _better_.

It is simply 10x more _valuable_. And that depends on the organisation you
work for, the state of the code base and so on.

Look at it this way - sports stars are regularly 10x, 100x more _valuable_ to
their team management than A.N.Other professional player. Take football
(soccer) - Ronaldo is a waaaay better player than I am easily 100x, but take
the newest signing in league 3 or whatever it is - can Ronaldo run 10x as
much, is he 10x as likely to put in a penalty or a free kick? No. it's
probably not even a question of twice as likely - it's percentages better.

It's just that those percentages _matter_ when the cup is on the line. I am
sure that Baseball statistics probably show this - the spread from top of the
league to bottom is unlikely to be 10x more runs scored

So more and more it's worth remembering that the value provided to an
organisation (and remember that's what you can charge for) is based not on
your intrinsic qualities but what you can do for them in their current state.

~~~
skrebbel
Small percentages matter when the game is competitive. Programming is not
competitive.

I agree with your argument but I think your analogy is bad.

~~~
ralusek
How on earth is programming not competitive? Coming up with the wrong data
model can result in millions of dollars in technical debt, a failure to fully
realize a product, or certainly allow a competitor to win out. Bad programmers
can structure a product so poorly that it is simply unpleasant to work on, and
you won't be able to hire or retain engineers.

I think moreso than most careers, a single software engineer is capable of a
tremendous amount of good or harm.

~~~
skrebbel
None of what you just described defines "competitive". A situation is
competitive where one's gain is, another's loss. There's no such dynamic at
play when programming, except _maybe_ career advancement in big organizations.
When I write better code today than I did yesterday, you, my teammate, will be
happier, not sadder.

~~~
throwawayjava
All of the things mentioned are ways that bad programming can "allow a
competitor to win out". Programming is competitive because markets are
competitive.

Now, markets aren't always zero-sum. But they are often competitive.

 _> When I write better code today than I did yesterday, you, my teammate,
will be happier, not sadder._

That's also true in football...

------
seba_dos1
> Three years later, I am still very much the apprentice.

Well, three years is really not a lot when it comes to developing an
intuition. Just enough to grasp some basics.

> a writer is someone for whom writing is more difficult than it is for other
> people

Yeah, I seem to recall Douglas Adams saying that the easier it is to read a
text, the harder it was to write it.

At the beginning of my career I was constantly being praised for how fast I
work. Well, I did stuff that worked, the effects were quickly visible,
everyone was happy.

Even though there were code reviews to weed out the ugliest stuff, I wouldn't
want to go back and maintain that software today :P

~~~
leggomylibro
It might just be one of those universal truths: you need to understand
something very well to explain how it works in simple terms.

Or as some smart person once said, "brevity is the soul of wit."

~~~
flukus
"If I had more time, I would have written a shorter letter" \- attributed to
just about everyone: [https://quoteinvestigator.com/2012/04/28/shorter-
letter/](https://quoteinvestigator.com/2012/04/28/shorter-letter/)

------
revskill
I use one rule: If it's easy to remove, then it's fine.

Because only then, i don't fear refactoring later.

So i'll get my goal: Easy refactoring for fun and profit.

Refactoring is often underrated. Actually i learnt more from refactoring
rather than "just make it work perfectly since day 1.

~~~
ravenstine
Most people talk about KISS, DRY, and YAGNI, but it's uncommon that I meet
anyone who actually values _replaceability_. I don't even mind some repetition
of code so long as groups of code aren't tightly-coupled and parts of an
application can be easily replaced with rewritten versions.

I had a boss once who was dumbfounded that I actually _wanted_ to refactor
code. I guess a lot of people want to write things "perfect" from the very
start, but that perfection seems to be a delusion most of the time. The best
way to know perfection is to see it in hindsight.

~~~
Wildgoose
I usually state it as "Optimise Code for Deletion" \- the best code is code
that can be removed completely because that means it can be rewritten cleanly.

~~~
ravenstine
I love that. :)

------
averros
It's very easy: most coders are undisciplined hackers, not engineers.
Unfortunately the prevalent macho coder culture (agile, and the rest of that
crap along the lines of "move fast break things") positively encourages
hacking away without much planning, design, or forethought.

Real engineers spend most of their time learning, thinking, designing, and
planning. Coding for them is mostly exercise for fingers, something which
needs to be done but ultimately providing no challenge. They learned not only
from textbooks but also from their own mistakes, and know what to watch for
and where to double-check themselves.

The outcomes are strikingly different: code produced by real engineers usually
simply works. No need to babysit it in production. It also solves the real
problem rather than "improving" on something which was adequate in the first
place (face it: most new software replacing the older one is worse - more
bloat, more bugs, harder to use). The real engineer understands that
complexity is THE enemy, and breeding (or dragging in) unnecessary complexity
is a hallmark of a freaking amateur.

Oh, and academia doesn't teach engineering. Your C.S. degree means shit. Old
codgers who remember punching cards and incantations like //GO.SYSIN DD * may
be tired of learning the shiny new toys and aren't up to the speed on the
latest jargon, but over the years of wrangling code they acquired wisdom, and
you'd be very well advised to listen to them.

~~~
bitblit87
I think labelling a development methodology and macho or not engineering is
disingenuous. Any methodology practiced without an engineering mindset looks
like that. Agile methodologies practiced by engineers looks like good
engineering.

~~~
averros
Methodology shmethodology. No management fad can replace thinking. Boeing 737
MAX is what you get when scrum masters get to boss around engineers.

------
werber
I've had this conversation a million times. I think when you're learning and
working on your own to build a skill, do it fast and do it over and over. When
you're working on a shared code base, you need to be more cognizant of your
actions, of maintaining the established styles and conventions. I've know very
few 10x or 100x programmers, and am not one myself. But I have had to deal
with people who sacrificed quality for speed and every time a code review for
those kind of people comes my way, I know I'm in for a ride that will take me
away from the work I need to be doing.

------
innocentoldguy
> Three years later, I am still very much the apprentice.

I used to think I’d get to the point where I could just sit down and breathe
out perfect code, but that doesn’t happen. As I’ve thought about the reasons
why, I came up with the following reasons:

1\. Writing code is an act of inventing. If what I’m trying to build already
existed, I could just go buy it and save myself a lot of time and money. It
doesn’t exist though. I’m being paid to create something new and unique. This
requires thought, trial and error, and multiple iterations to get right.

2\. The software development landscape is not a static one. I used to build
commercial buildings with my dad. Once I learned that studs should be set at
16” on center, how to measure and cut complex angles, and how to finish
cement, I never had to learn those things again. They were pretty much static
and I got to where I _could_ breathe out a plumbed wall without thinking about
it. In the software industry, developers are constantly having to learn new
things. New languages become popular, companies jump on things like Kubernetes
because everyone else is, the JavaScript community cranks out new libraries
and frameworks on almost a daily basis. While the fundamentals of recursion,
looping, and conditionals remain the same, the syntax, idioms, and best
practices are constantly shifting. After 30 years of programming, I don’t
think I’ll ever stop being an apprentice in at least some aspects of my
career.

~~~
djmips
Sometimes I wished I was a baker or a carpenter.

~~~
innocentoldguy
I do too, until payday.

------
radosc
I do not believe the ceramics story. It is either nice fake to prove the point
or what that particular teacher valued was a natural expression rather than
perfection. Applying that principle to photography would mean that every one
of us is now an artist because we made 1000s of vacation photos and
photographers that used just film cameras are bound to produce lower quality
work. I've also seen many startups that generated a lot of low-quality code
that became a tech debt super fast, and all it needed is someone stopping the
line and rethinking the whole thing.

------
skybrian
I suspect there may be better ways to practice, rather than just doing it
more? Some people put effort into memorization of commonly used idioms.

Here's another dubious analogy: when learning music, you do need to practice,
but playing a song all the way through a bunch of times is a rather
inefficient way to practice it.

~~~
megous
Other way of doing it more, is not just doing the same/similar thing again and
again, but writing/reading large amount of very different programs. One day
you do web app, other day you write a kernel driver, third day you write a
scraping app, fourth day you write a tunel driver to get networking over USB,
fifth day you reverse engineer some random piece of HW you have laying around
and write alternative firmware for it to teach it new things, and so on. (it
may not be days :))

Each of these things will branch out into different areas. You may need to
write a text parser. You may need to design a USB protocol to relay packets.
You may need to learn a processor architecture, calling convention, assembler
mnemonics.

Over time you'll gain a lot of knowledge and you may be able to cross-apply
plenty of it accross the domain boundaries.

------
topmonk
I'm surprised the author didn't mention _learning_ about programming.
Programming did come out of the field of computer science, after all.

Not that I think one should never do any hands on practice, but if you spend a
large chunk of time learning the concepts of different mathematical fields
related to programming, as well as the teaching of other programmers, you'll
become a much better programmer than you ever could otherwise.

------
overgard
I really disagree with this. There's a point on most projects where you've
learned about all you're going to learn from it. Maybe it's still growing, but
it might not be teaching you anything new. The best way to get good is
diversity of experience, and the best way to get diversity of experience is to
do a lot of different things. The more diversity you can pack into a smaller
time space (without just cramming and rushing things), the faster you'll get
good.

If you've only been programming 3 years, you're definitely going to make a lot
of mistakes. That's good! That means you're pushing your boundaries and
learning. Peer review feedback isn't a mark of shame; and being attached to
your code is a _bad_ thing. At the end of the day, coders vastly overvalue
code beauty and aesthetics, and overestimate how long their code is really
going to live. (I've been a professional for about 11 years, and while I take
pride in my work, a lot of the companies I worked for either folded, pivoted
to a new product, replaced some of the things I wrote with open source
solutions after the problem space had become less novel and a proprietary
solution didn't make sense anymore, or a billion other reasons why the code
didn't need to live anymore. I'm not saying that's an excuse to write shabby
code, but a lot of times "it works and it solves the problem at hand and the
code isn't a disaster" is when you should stop working on it).

I think coding is a lot more like creative writing than it is like
engineering, and if you want to get good at creative writing you make a point
of writing a lot of stories, even though a lot of them won't be good. Or if
you're composing music, you write a lot of music, you don't focus on one piece
forever. Anything where you make, the more you make, the quicker you get
better at it.

------
thanhhaimai
I think we’re conflating learning and producing when we discuss quantity and
quality. During learning time, quantity is what you want to focus on. During
work mode, you want to slow down and think carefully. Only when you are very
sure about the selected solution that you start going quickly. Applying the
story of James Joyce in a broad stroke might be misguided.

If I have to pick, I’d err on the side of doing more than trying to slow down
and write perfect code. When you’re junior, your definition of “perfect” code
might be very different from others’. You might be reinforcing bad habits
rather than learning. I’ve seen junior SWEs insist on spending hours
eliminating a couple lines of duplicated code by pulling them out into
functions to achieve their perfect code. At the same time, they neglect basic
coding hygiene, put defensive nullptr checks everywhere, and not design for
readability and testing.

------
alexgmcm
The author has another blog post about learning to play the violin and how it
taught him the importance of deliberate practice which I feel is probably what
he is also trying to get across in this post.

I am experiencing something similar as I continue to study the classical
guitar.

I agree that the importance of deliberate practice over just coding and coding
really does matter - in my day job I will write many lines of code doing the
same string processing etc. (I work in Data Science) but when I am trying to
learn I really want to think if I am doing it in a Pythonic way, how I might
make the code more reusable and so on.

------
derpherpsson
I spent my first 4 years after the university at a company with very little
quality control. We had to talk the bosses into having code reviews. When we
began having code reviews my older colleagues never complained about anything
- everything went through.

That truly was quantity over quality. Oftentimes I had to wade through piece-
of-shit code that really made my soul hurt. Really. Bad.

But in hindsight that was good. It's good to have spent 4 years ONLY writing
code 8 hours straight 5 days a week.

But I never, ever, want to go back to anything like that.

~~~
photonios
This mirrors my experience. I spend the first two years of my career working
somewhere where pretty much everything went through.

There were some projects in the company lead by developers that were some of
the best I ever worked with. They upheld very high standards and the code was
some of the best I've seen. Most projects were a total mess and nobody asked
questions or reviewed code.

I worked on both type of projects. I think it really helped me. Some projects
I just wrote code hours and hours on end without little regard to quality, but
later on other projects within the company I was exposed to people and code
that was significantly better.

------
mamon
>> The best writers write much more slowly than everyone else, and the better
they are, the slower they write.

By that metric George R.R. Martin is on track to be the greatest writer of all
the time :)

~~~
felipemnoa
Nah. He just got distracted by the trappings of being famous.

~~~
mamon
No, he had written himself into a corner at the end of the "Dance of Dragons",
and then waited for the tv show screenwriters to help him figure out how to
proceed from there - that's the most probable explanation I can come up with
(hinted by some statements from his interviews).

~~~
portroyal
I think HBO just made it way easier. Once I heard the series would be a show,
I knew we'd never get any more books because the lull between A Feast for
Crows and Dance with Dragons was something like 5 years. At that rate, he'd
need another 15 to be done while gallivanting on other fantasy
titles/collections/anthologies/wtf and endorsing everything under the sun once
the first three books gave him clout.

I'm definitely a little bitter about it, but I've accepted it. Parris needs
the royalties.

/salt: Somehow, within that time, Robin Hobb managed to spit out a trilogy
seemingly once a quarter. Thankfully, Steven Erikson came along and wrote The
Malazan Book of the Fallen, which, if you like books, honestly puts ASoIaF to
shame on numerous levels (and has the benefit of being done).

------
tschellenbach
For me the best analogy is a carpenter tightening screws. When you start out
solving a particular problem part of the scope and required functionality is
always not 100% clear. So you start out with an implementation which favors
flexibility over things such as DRY or performant. As you learn more about the
problem you start to optimize.

One of the biggest mistakes (the biggest one is probably not writing tests) I
see junior engineers make is trying to optimize before fully understanding the
required functionality.

------
wayfarer2s
I'm surprised the author's takeaway from the Joyce quote was disillusionment.
He's actually quite close to the secret sauce. I don't think writing more code
and ending up with less code are at odds. In fact, I think you need to write
more code to end up with less. You write more code in order to understand the
problem space. Once you understand the problem space, you can then refactor
everything that you wrote into more concise code that more accurately reflects
the problem.

James Joyce wrote Ulysses at the rate of a hundred words per day if you only
consider the finished product. However, I doubt every word that Joyce wrote
ended up in Ulysses. I'm sure he did quite a lot of cutting and rewriting.

The takeaway from me from the two quoted stories was that quality and quantity
are not at odds, but instead are the yin and yang of productivity. They
reinforce each other. The more things you produce, the more patterns you are
exposed to which in turn leads to higher quality since experience leads to
efficiency, giving you more time to get things right.

------
LarryMade2
I think when you are starting some new concept, that you are learning as you
go you need to just try to do your best of throwing stuff on the wall to get
it to work, refactor a lot and keep grinding away. During this time you are
building the "Big picture" of what it is.

Once you get a good enough big picture then you probably will start to realize
where how to optimize the data and create better methods, but even there it
still never stops, you now know the system, and can figure out what you need
from the technology to construct a better platform.

The databases I've worked with for over 20 years have evolved as I have added
more functionality, I have been able to identify where the priorities were as
well as how to make it function more dynamically. I didn't really get the big
picture for a decade as they were sill doing part of it analog and only
requested (revealed to me) more functionality as the system grew more capable.

You may think you know it all now, but I would think there's still a lot more
road to be covered after only three years.

~~~
flocial
This was my first thought. I think beginners take better to volume but
eventually we all hit a wall that takes more deliberate practice and deep
reflection. Even then some concepts will be out of reach or take an
exceptional teacher to break down. That doesn't even touch on the limits of
individual abilities which we all face at some point.

------
ken
As one of the million people who tried to read Ulysses and failed, I'm not
sure I'd hold up Joyce as the example of what programmers should aspire to.
There's plenty of popular and even good creative works which were written
quickly or even under external time pressure.

------
3pt14159
This article is good, but these conversations here on HN always bug me.

Yes—write a ton of code.[0] Just do it. Make your favourite couple languages
extensions of yourself.

Yes—think through your code really clearly. Spend a day on your migration or
other data-structure altering changes. They're going to echo throughout your
whole application and, ultimately, organization.

[0] The closer you get to the API, the faster you should code. Not the
interface definition itself, that should be thought through, but the code that
responds to a call to the interface. The serializer, the part of the
controller that calls the render, these parts are easy. Just roll them out.
The models and migrations are much more important. Spend time there. It's not
an all or nothing thing.

------
muzani
I've been facing this in the past year after I started doubling my consulting
rates. A part of me wanted to do 2x better work as well, and that just ended
up in getting less work and lower quality work done.

Taking my sweet time is definitely not productive either.

I find the balance is to treat it like sketching. Instead of trying to "print"
out code, well designed from scratch, from top to bottom. It's better to
sketch out the main "lines" of it. It involves a lot of erasing past lines and
old code, or even making redundant code at times. You definitely need a lot of
scaffolding and placeholders, especially early on.

------
gumby
This is why programming (as a profession) is engineering and is different
computer science (as it is today -- when I was a student 40 years ago it was
still turning into a "science"). Engineering as a discipline is at its heart
balancing tradeoffs of factors like time, cost, weight, strength, efficiency
etc. There is no single pole on any of these axes that can dominate, even
though for illustrative purposes it's generally useful to do so when writing
an essay.

(Also three years is a really short time, though the author seems to be using
that time well in order to learn and meta-learn).

------
rejschaap
> “Refactoring code” would be something left to the apprentice, not something
> that I, the master who has churned out enough ceramic pots, would be
> bothered with.

The master potter does not churn out pots that need to be fixed. He focuses on
quantity to get to quality faster, that is the whole point of that story in my
opinion.

Also, "refactoring code" should not be seen as such a separate activity that
it can (or should) be done by other people.

------
saint_abroad
The point as applies to individuals extends to projects also:

 _> Programming system builders have also been exposed to this lesson, but it
seems to have not yet been learned. Project after project designs a set of
algorithms and then plunges into construction of customer-deliverable software
on a schedule that demands delivery of the first thing built._

 _> [...] plan to throw one away; you will, anyhow._

Fred Brooks, The Mythical Man-Month (1975)

------
jnty
People used to heavily criticise Minecraft from a technical point of view.
Their criticisms were often entirely reasonable - it was at one point a very
inefficient and unstable piece of software. However, it's now the second best-
selling game of all time. Sometimes it's better to churn out a release and fix
the problems later than let quality worries block you from achieving anything.

------
tdsamardzhiev
Interesting. I've "evolved" in exactly the opposite way. I used to go for
quality all the time. Nowadays I'm pretty confident getting things done
swiftly (and thus enabling more code/design iterations) works better for me in
both the short and the long term.

That being said, I definitely don't pretend to be the Thomas Mann of software
engineering.

------
weeber
Doing it more can provide better result _only_ when it is allowed to trash the
previous iterations to use the latest one.

This is _not_ the case in the industry, we _cannot_ change everything in a
product at each iteration. This is why at least a little care and architecture
have to be done before doing it and trashing must be made with care.

------
segmondy
BTW, for anyone who wants to know more about the context, it's from the book
"Art & Fear"

------
wchildhn
This is why there are so many vulnerable products in the market and engineers
are tired of fixing them. People do not think before they start and they are
confident enough to say that they have learned from their faults when they are
actually too tired to complete the fixing process.

------
Dowwie
One prolific programmer who comes to mind from this article is Nikolay Kim,
author of the Actix projects in Rust, aiohttp in Python, and many other open
source projects. The Actix Project has evolved so much over a short period of
time. The author learns by doing, with haste.

------
temdbej
Part of me feels like bootcamps are effective for some because you will
inevitably start getting it when you do it for 15+ hours a day every day for
an extended period of time (which is more than you’d likely do on the job or
in a more theoretical CS degree)

~~~
toomuchequate
>when you do it for 15+ hours a day every day for an extended period of time

Does this happen? I've programmed daily for ~11 hours/day between 2 companies,
but at 15hrs/day I feel like there is diminishing returns.

~~~
opportune
Why 11hr/day?

------
kriro
Write more, care about your craft in general terms. Then it'll get better.
It's a skill, skills get better with more practice. Premature optimization is
the root of all evil.

------
pojzon
I think that being a professional is exactly that:

"Being able to balance those two core things to meet client needs."

Any kind of extremisms is bad, no matter where applied.

------
paxpelus
I have worked many times on ugly and on beautiful code. What I consider ugly
is not always ugly for other developers and the other way around.

------
pier25
FYI the ceramics story comes from a book called "Art and Fear" which I highly
recommend to any creative individual.

------
edpichler
This is interesting reading. Continuous Delivery fits perfectly on this idea
of continuous building and learning.

------
ensiferum
For learning, produce as much as possible. For production, produce as little
as possible.

------
lazyjones
People who want to write "beautiful code" are not role models, don't listen to
them. They are vain and not productive. Listen to the people who finish
correct programs on time, or mostly working prototypes in hours or days.

How to recognise the former group: they obsess about coding and other
standards and processes, plan and discuss too long how to implement something
(plan _what_ to implement, do it, then improve it when it's done; inspiration
comes from working on something, not from thinking about it) and never even
meet their own estimates for how long it'll take them to deliver. They will
tell you they are taking so long because they haven't decided yet how to best
implement something, but they don't even have a straightforward implementation
(there's always one). If they were truly concerned with "the best way", they'd
have several solutions implemented already, together with metrics and
benchmarks. They haven't, because they're vain impostors and not capable
programmers.

~~~
rvanmil
I think it’s a balance. At the other end of the spectrum are the “cowboys” who
are productive by writing sloppy code with bad architecture and are either
oblivious of or just ignore the huge pile of technical debt they pass along to
the people who get to maintain their code.

~~~
lazyjones
Technical debt within a working codebase is a much, much better problem to
have than not being able to launch or even demonstrate your product. It's
really overrated. I left a huge pile of it in my previous company (amassed
over 18 years of programming in Perl) and guess what: it's doing great, more
profitable than ever before. The code has been slowly enhanced, some of it
refactored. Code quality (as in "beauty", not correctness) is the least of
your problems in a startup, although it will look bigger for those who have to
work on it (pity them but don't overemphasize).

~~~
Ma8ee
Yes, but the other side of the coin is having a codebase that is so old and
such a mess that it can't be changed or upgraded without a tremendous cost.

I have worked for a company that eventually went down because there was
absolutely no separation between business logic and user interface. When no
one any longer wanted to pay for a system with an ASCII-interface (this was
about 1995), they had to throw out about 5 million lines of code and never
recovered.

I've worked with systems that had to be thrown out because no one any longer
wanted to pay for a week of work for something should be possible in two
hours.

Either extreme is stupid. Of course you have to ship. And in early stages it
often makes sense to accrue debt to get fast to the market. But of course you
also have to be able to be nimble and move fast even after two years and five.
You can't do that if all your resources are tied up in interest payments.

~~~
lazyjones
> _When no one any longer wanted to pay for a system with an ASCII-interface
> (this was about 1995), they had to throw out about 5 million lines of code
> and never recovered._

Kinda obvious what their actual mistake was then...

> _I 've worked with systems that had to be thrown out because no one any
> longer wanted to pay for a week of work for something should be possible in
> two hours._

I see a pattern there.

> _But of course you also have to be able to be nimble and move fast even
> after two years and five._

You can also go broke while chasing this illusion, twice. Whether as startup
or established company with a "big ball of mud" codebase.

I'd rather tackle the "no one wants to pay" problem in a profitable company
than a complete rewrite, or even trying to boot up a new company while, in
addition to all the other problems involved, trying to write "beautiful code",
thank you.

~~~
Ma8ee
I don't know anything about you personally, but my experience with people that
argue like you is that they don't understand or don't care about maintainable
code at all. So every time someone tries to argue for something like best
practices they get shouted down as completely unpractical and out of touch.
The problem is that the people doing the shouting is often the ones that
produces code at high speed. They are productive while everyone else has to
clean up their mess.

Maybe I wasn't clear enough, but "no one wants to pay" and profitabitity just
don't go along very often.

------
WangYekun
I think to second is good.

------
WangYekun
I think second is good

------
externalreality
Programming is simple. Domains and interfaces are difficult. People over
engineer stuff. People like to think they found the key to hidden wisdom. I
believe I just summed up 90% of the difficulty with programming.

Just for the record procedural programming and functional programming are the
only two styles of programming to me that make sense. Procedural because its
how the machine model works and functional because its how a mathematical
description of computation works. WTF is OOP (how the over active imagination
of a child works I would reckon).

~~~
osrec
OOP attempts to map to real objects, (and sometimes not so real objects). I
know it's hated by functional purists, but it really does make it easier to
think through problems. I personally don't hate it.

~~~
externalreality
Functional purists are the only one's who hate it. OOP by its very nature
encourages developers to make bold abstractions prematurely (where prematurely
is interchangeable with unnecessarily) and subjectively. Mean while the
procedural programmer (Golang) has already finished the segment of the program
having written one big function. If a piece of that big function is needed
elsewhere she factors it out. Most of her program are simple loops and
conditionals. Programs are easy. Programs are easy, why complicate something
that is easy.

The machine should also guide the programmer as much as possible. I wish
Golang had refinement types like Liquid Haskell or ATS. Some simple static
analysis to cut down on crufty slow runtime test suites.

~~~
true_religion
Nothing stops someone from waiting till they hit a pian point before
refactoring during OOP. It's how I work.

But then again I mostly use Python and JavaScript which are multi paradigm so
perhaps my mental model had evolved because of that.

