
What I Wish I Knew When Starting Out as a Software Developer: Slow the Fuck Down - chx
http://blog.salsitasoft.com/what-i-wish-i-knew-when-starting-out-as-a-software-developer-slow-the-fuck-down/
======
stevewepay
The one bad habit you learn from coding in school is you take a project and
then throw it away. So speed does count when it comes to finishing an
assignment so you can goof off, go party, etc. And then you never see it
again, so who cares if the code sucks as long as it produces the outcome you
want.

What you don't learn in school is how to write maintainable code. This is a
much different style of writing code, and much more valuable once you go out
in the "Real World". I'm not sure if there are CS programs out that start with
a small project and then force the students to make massive changes to that
project throughout the course of the year, but to me there is immense value to
that. Even better would be if they had CS101, CS201, CS301 and the students
taking CS201 would be forced to dig up their project from CS101 and work on
that, CS301 would work on the code from CS201, etc. It's eye-opening how much
you forget about your code after a few weeks, so it would drive home the
notion of commenting, writing easily readable code, etc.

~~~
grecy
> _I 'm not sure if there are CS programs out that start with a small project
> and then force the students to make massive changes to that project
> throughout the course of the year_

I studied Software Engineering at Swinburne University in Melbourne Australia,
and we did exactly that.

One subject was "Software Maintenance Project" where we took an existing code-
base we didn't write (a front-end for laTex for our year, the CVS code base
for the next year students) and continually made changes to it. Halfway
through the course we had to deal with changing requirements. We were graded
on the quality of our code and how well it fit the existing style etc., not
how fast we did it.

We also did a full-year final year project with 16 of us where we created a
BIG code base from scratch. We decided to use an iterative approach (our
choice) and so over the year we ran 6 iterations continually building on what
we'd already done.

We also did awesome courses like "Personal Software Process" to teach us
discipline in how we personally approach writing code.

EDIT: Sometimes I post to HN "hire/resume" threads about my hire-ability and
how I personally think I'm "better" than the average person who studied CS
because of things like the above. Normally everyone disagrees and says as long
as I can code, it doesn't matter that I studied Software Engineering and am a
certified Engineer. It's for reasons like the above I still personally feel
I'm stronger than the average CS grad.

~~~
mattgreenrocks
FYI, you are stronger than the average grad. People get pretty defensive when
it comes to skills; nobody wants to believe they're below average if they're
frequenting this site.

My one piece of advice: keep studying and practicing making beautiful
software, in and out. Be careful who you take technical advice from; the
industry right now is flush with cash, and thus there is a huge incentive to
talk more than produce. Projects are often killed as quickly as they're
started, causing people not to practice program design.

------
stevebot
I was lucky enough to start my career at a place which appreciated stable
working software and the principle of slowing the fuck down. Then I had the
unfortunate experience of changing jobs and ending up at a place where speed
was king. Developers were worshiped by their ability to blast through
projects. I would call this the "Get Shit Done" principle.

What I have found is that you need a balance. "Slow the Fuck Down" gets you
working software, but if that takes you twelve months to a year, you lose the
sense of progress and accomplishment that having a live product gives you.
There has to be a healthy balance between "Slow the Fuck Down" and "Get Shit
Done" which usually involves cutting features, prioritizing and temporary
fixes. Most projects using MOSCOW is a good place to start with this.

~~~
sanderjd
I think it's unfortunately common to have "Get Shit Done" people that work on
making greenfield stuff quickly and "Slow the Fuck Down" that make that stuff
work and keep working, which is both technically and politically.

Also, what is MOSCOW?

~~~
V-2
Presumably
[http://en.wikipedia.org/wiki/MoSCoW_method](http://en.wikipedia.org/wiki/MoSCoW_method)

------
joesmo
In addition to the negative impacts on code and the actual product of going
too fast, there is the additional problem of working at an unsustainable pace.
That then becomes the norm and is expected even when it can no longer be kept
up. This isn't a problem specific to programming. It shows up in almost any
job.

Over-performance will never be rewarded. One might get a slightly higher bonus
if one is lucky, but generally it'll be forgotten. All those long days,
nights, and weekends spent working non-stop will be immediately erased from
the company's recollection once the product ships. They will be especially
forgotten once the developer can no longer sustain that pace which now has
become the norm and needs to be reprimanded (despite still being objectively
productive).

In the end, it's only the developer who suffers, and it'll be great suffering
up to and including mental and physical disability from not slowing down.
Excellent advice.

~~~
MCRed
Absolutely true. We need a culture where management is done by engineers.

This means we need to step up as engineers and start becoming managers.

But we also need to refuse to work for managers who are incompetent.

IF you're a programmer and you're reporting to someone who is not the CEO and
is not an engineer, then you need to find another job and tell them why.

Time to stop working for startups run by CEOs who have nothing more than a
business degree. IF the CTO is a competent engineer and the CEO has some
domain expertise that's fine.

At amazon my boss, literally, had wanted to be a prison guard and gone to
school for that. He was a terrible manager. They didn't even hire engineers to
be managers, they just got these random incompetents. His boss was right out
of the DMV. It was that way all the way up the chain of command to bezos. When
nobody between you and the CEO, including the CEO, is a competent engineer,
you're not going to be managed well. (and Amazon's software quality reflects
that, despite the constant hype the site is a tragedy of bad design.)

~~~
DanBC
> Absolutely true. We need a culture where management is done by engineers.

I'm not so sure, you want engineers to be engineering. You want good managers
to be managing. The skillsets don't have much overlap and people who are good
at one might be lousy at the other.

~~~
MCRed
Someone who does not understand how software is produced cannot manage the
process of producing software.

It's easy to learn to manage programmers, I've done it, and I did it by
dealign with a lot of bad managers.

In 25 years I've yet to meet a manager who was good at managing software
development who did not have an engineering background. At best, the best
managers sat by and let the programmers run the show and they themselves just
helped with interpersonal problems and hr, and spend their time doing some
project management type efforts.

The idea that managers possess something magical that engineers don't have is
false.

Or maybe over decades I've just randomly never seen it. And I've worked at
places like Amazon and Microsoft-- at amazon the managers were not engineers
and it really sucked. At microsoft the mangers were engineers and at least in
that regard it was much better.... except at the higher levels where it became
political and the mangers stopped being engineers, and thus projects got
behind.

------
the_hare
Maybe I've had it pretty hard but from my personal experience, often what
happens is that the reason why I can't write unit tests, documentation, or
spend enough time in a code review so that the code is maintainable is because
either the project manager or the client is always screaming at the top of his
lungs that he needs everything done by yesterday.

~~~
inDigiNeous
Just say how long you will think it will take realistically. Project managers
don't usually understand the code. Be as honest as you can be.

Somebody somewhere said that:

"Estimate the time it takes to finish the project. Then multiply that by 8"

Surprisingly, this usually lands in the correct estimate. Best advice ever.

~~~
JeremyMorgan
"we don't have time for that. You're a rockstar. Make it happen".

~~~
AnimalMuppet
"You don't have time for me not to do it. I'm a rockstar. Listen to me."

Yeah, I know that it's not likely to work...

~~~
JeremyMorgan
Sometimes it does. It's the battle that every developer, especially leads,
will face quite often in this career.

------
V-2
Devil's advocate:

> Peter asked Zawinski, “Overengineering seems to be a pet peeve of yours.”

> “Yeah,” he says, “At the end of the day, ship the fucking thing! It’s great
> to rewrite your code and make it cleaner and by the third time it’ll
> actually be pretty. But that’s not the point—you’re not here to write code;
> you’re here to ship products.”

> My hero.

[http://www.joelonsoftware.com/items/2009/09/23.html](http://www.joelonsoftware.com/items/2009/09/23.html)

~~~
senderista
Anyone who used Netscape knows how that approach turned out.

------
fragmede
"Slow the 'f down" is the _wrong_ thing to say. Younger-me is totally capable
of finishing in 3-hours and then lying about it for 2 more days. That results
in a slow down without any improvement to the code.

The more important lesson I would impart upon my younger self is that the code
_isn 't done_ until it's been committed, there's been a README written, and
some testing has been done. Who cares if it works? Pft, that's the _easy_
part!

If your commit messages after the first few aren't more specific than
'updated' or 'new stuff', you fail. If the README is 1 line long and just says
'I made a thing', you fail more.

And then there's this:

You dig up old code, and it really sucks. The idiot that wrote it should not
be allowed behind a keyboard! Y'all know the end to this story - the 'blame'
command points the finger... at yourself.

There's nothing more humbling than that.

Proper software engineering isn't about writing code, it's about maintaining
developer sanity, especially in the face of fast-moving business requirements.
Don't push back hard enough and the sale's guy's unrealistic schedules start
to dominate. Push back too far and you start writing a frameworks on top of
frameworks instead of deliverable code. Push back too far and you end up with
lazy engineers who drop features because they're "too hard" to test (Hello
Google, so glad you decided not to drop ext4 support in ChromeOS's Files app.)

But in today's fast-moving world? Run. Run as fast as you can. Keep running.

------
frandroid
> (The dreaded Windows 3.1 "General Protection Fault" error made such frequent
> appearances that my boss, the company's CEO, took to saluting me with a
> sardonic "Salut, mon Général !" when he passed me in the hallway.)

Ouch!!

------
bstpierre
Going slow is often a good idea, but part of the wisdom that comes from 20
years writing software is _knowing when_ you should choose between slowing
down, coding like hell, slapping something half-working together, etc.

------
rpedela
I generally agree with this post. What I have found to be ironic, personally,
is that good automated testing often takes a long time to implement and it
feels like it takes forever sometimes. However it usually shortens the overall
development time and increases quality because you can add new features, re-
factor others, etc and then just run the tests to make sure you didn't break
something. And if you did break something, you know immediately what it is
wrong and can fix it.

~~~
sanderjd
Lots of people seem to think that an automated test suite is a guarantee that
you know when you've broken something. I have never found that to be true.
Sometimes I have even found it to be a dangerous idea, leading to complacency
in reasoning about the potential impacts of a change and actively verifying
its behavior. It's great to have a good automated test suite, but it's much
greater to also have people using and verifying software.

~~~
rpedela
That is why I used the adjective "good". Like you said, just having an
automated test suite is not necessarily useful. Let me define what I mean by
"good".

A good automated test suite has a very high (>90%) coverage of all cases that
an actual user may encounter in the real world. It is extremely difficult to
achieve this in the initial version of the test suite. The goal initially
should be to build a test suite that can be quickly and easily updated so that
>90% test coverage can be achieved over time.

When people are "using and verifying software" or when there is a bug found in
production, the bug fix should be accompanied by an update to the test suite.
This way this particular bug will never happen again in production. In
addition, you never let your guard down and continue this process for as long
as the product exists. Over time this process will yield a test suite so good
that you can assume that a particular change hasn't broken existing
functionality even though there isn't a 100% guarantee.

The cool thing now is that build tools are so good that you can codify some of
this process into the build to ensure commits are tested before merged. And
commits are reviewed to verify relevant tests were added or updated before
merged.

~~~
sanderjd
I'd be curious how many people feel like they have automated test suites that
achieve greater than 90% coverage of user actions (presumably this means the
tests are at the integration level). Really good integration test suites are
definitely great for catching regressions and being confident in making
changes, but in my experience they are also difficult to build, slow to run,
and expensive to maintain. Which is why, I think, people often focus more on
getting high coverage of unit tests, which are much lower cost, but not nearly
as useful for catching regressions.

------
robohamburger
Slowing down was one of the hardest and best things I have ever done.

It can be hard in environments where even hours longer on a piece of work can
make the difference between happy customers and sad ones but it pays off quite
quickly.

You write better code which is easier to maintain and has more tests. In doing
so you are able to improve your craft which is hard to do when you are rushing
yourself.

Once you get better you will be more productive and can get work done faster
but with acceptable quality.

------
known
Writing software and Selling software need different and distinct skills.

------
vijucat
Nice article. "I'll quickly rewrite the engine", said no wise developer ever.

------
michaelochurch
Pardon me for this, but I'm a bit irked by being taken out of context.

 _Most obviously, Michael urges young programmers deciding how much effort to
put into their work to "ebb towards underperformance"._

That's not what I said. From the source (on Quora, here:
[http://www.quora.com/What-do-software-developers-
age-30-and-...](http://www.quora.com/What-do-software-developers-age-30-and-
over-know-now-that-they-wish-they-had-known-in-their-20s/answer/Michael-O-
Church)):

 _3\. Recognize underperformance and overperformance and avoid them. There are
a lot of low-effort players who stay employed for years. This isn 't a bad
strategy if you're settled, but I wouldn't fall too low. That said, the only
people who typically get fired for underperformance are the people who fail so
badly that they generate work for others. People who hide and do little tend
not to make any enemies. At the same time, be cautious of overperformance.
This isn't like college where challenging your professor's ideas could earn
you an 'A' if you argued your point well. Overperformers often also generate
extra work for their superiors and colleagues and draw unwanted attention
(see: McNulty in The Wire) and are more likely to be culled for "performance"
(98 percent of "performance management" in companies is politics) than
underperformers. I'm not saying that you shouldn't work hard and do a good job
and learn as much as you can. That's not necessarily overperformance. In my
experience, though, overperformance is much more dangerous than
underperformance. It can get you just as fired and it will happen a lot
faster. If you end up stuck between the two, prefer underperformance._

I'm not saying that people shouldn't work hard or do a good job. On the
contrary, I think young people should bust their asses at growing the skills
and contacts that will serve them well for the rest of their lives. I'm saying
"avoid overperformance", and _overperformance_ isn't the same thing as "doing
a great job". I'm saying, "don't become like McNulty on _The Wire_ " (or a
certain person at Google who tried to prevent a product failure and got burned
for it). McNulty is a textbook overperformer: he loves the job, it doesn't
love him back, and he puts so much into it that it destroys his life and
career.

Sorry, but I'm pretty fucking pissed out this being out there like that. That
was way the fuck out of context. I wasn't happy with the Lifehacker edit
either but I didn't speak up about that because I didn't see it as a big deal.
But I am definitely not telling a generation of people to slack off at their
jobs.

~~~
marktangotango
>>I'm saying "avoid overperformance", and overperformance isn't the same thing
as "doing a great job"

Can someone explain this formulation of 'performance' without referencing "the
Wire"? Ie is it simply long hours? Or is it long hours coupled with getting a
lot done, in a good way? Or is it getting a lot done, and breaking things for
everyone else? Or ...?

~~~
sheepmullet
Basically going outside of the, often implicit, boundaries of your role.

For example if you are a developer and realise your project _needs_ to engage
another team NOW for a critical deliverable due in 3 months and you spend your
time on this task then you run the serious risk of pissing off both your
manager and the project manager.

Or for example putting together a prototype that shows how another teams work
could be automated.

Or pointing out flaws/discrepancies of a high profile product. Or telling a
senior manager how a project is really doing, etc.

The bottom line doesn't matter as much in terms of respect and career progress
as it should. There is a misconception that you can get away from politics if
you work for startups or smaller firms but that's just not the case.

~~~
michaelochurch
You nailed it. My upvote is not enough, and you will probably get fewer than
you deserve for this post.

------
branchless
I find it amazing that people swear in the title. Surely the author must have
the self-awareness to realise that few will be impressed and many will be
turned off.

~~~
bradleyjg
It's a puerile attempt to be edgy or authentic. Not that it shocks me,
judiciously used swear words can be effective -- most often in spoken English,
but occasionally in written as well. It just adds nothing to this title.

This case from yesterday:
[http://fuckinggodateformat.com/](http://fuckinggodateformat.com/) is slightly
better. It tells the reader that the author of the page doesn't like the go
date format in a succinct fashion. Though, on the other hand, it primes you
for a rant rather than a cheat-sheet.

~~~
mod
Of course, that guy did a PG version, too:

[http://flippinggodateformat.com/](http://flippinggodateformat.com/)

------
MCRed
20 years ago, colleges taught you to program slowly, with good architecture
and with maintainability. When I was taking CS courses we were taught to
flowchart our programs, write them all out, and really create the software on
paper before even touching a computer.

I've observed that programmers from successive generations become more and
more likely to just sit down and start writing before they've even had proper
time to think.

I think there's a spectrum, with one extreme example being the person who
writes 1,000 lines in 2 hours of code that is buggy and unmaintainable but
that the boss is really impressed because it does %70 of what is needed. These
guys really impress PHBs.

At the other end of the spectrum is the guy who gets the same assignment, does
nothing but sit in his cubicle thinking for a week. And then over the course
of a day writes 100-200 lines that does %90 of the assignment, and with no
bugs.

Current culture seems to favor the former guy-- which is why we have unit
tests (to catch all his bugs) and the assumption that code is crap. There
isn't much cultural support for the latter guy... but those guys, in my
experience are the better programmers.

For trivial programs speed is king, but trivial programs can be done by either
guy with a difference of a few hours in time to completion.

For programs of significance... the slower guy can save you months or years
and even cut your required engineering headcount.

But that guy doesn't seem to be recognized for what he does-- in fact, he's
often perceived as not working as hard, and is many times interrupted for no
good reason, but because they think he needs more work.

~~~
mortehu
> the person who writes 1,000 lines in 2 hours of code that is buggy and
> unmaintainable

> the person who gets the same assignment, does nothing but sit in his cubicle
> thinking for a week. And then over the course of a day writes 100-200 lines
> that does %90 of the assignment, and with no bugs.

I think you're leaving out the person who writes the buggy and unmaintainable
version in 2 hours, in order to discover any pitfalls they failed to imagine
before starting the project, then spends the remaining 38 hours of the week
thinking about the proper solution to both the foreseen and unforeseen
problems.

