
Confessions of an Intermediate Programmer - zaidos
http://www.michaelbromley.co.uk/blog/65/confessions-of-an-intermediate-programmer
======
akbar501
I've found the following really sets apart my programming now vs. earlier in
my career:

1\. I write and rewrite more now. I view the first time the code works as just
the first draft (like I would with a paper). Earlier in my career I thought
that making it work meant I was done.

2\. I spend a lot more time thinking about what's happening in the code and
why. I have found some of my best work to happen after days of thinking about
small bits of functionality.

3\. I get the domain (ie. the big picture) much better. This is insanely
valuable and helps me step back.

4\. I listen more to opposing views. That's not to say I don't argue my point,
but afterwards I spend time to rehash what the other person said when I have
no pressure to respond. This guides my thinking a lot as it give me an
opportunity to change views/positions.

5\. I'm increasingly tolerant of other technologies. I use x, but y must be
good too b/c smart people use it.

5.a While I'm more tolerant, I'm less distracted. When I was younger, I spent
more time switching technologies to learn "new things". Now I spend more time
going deeper on my current stack to learn new things.

6\. I now think its ok to write code in a "non optimal" way if it makes it
easier for the entire team to work with. I don't believe in writing to the
LCD, however I do believe programming just a little above the team's moving
average capability is probably better than writing above everyone's head
(whether by me or someone better than me).

~~~
collyw
> I'm increasingly tolerant of other technologies.

I would like to think I am, but recently I have noticed that everyone seems to
want to jump on the NoSQL bandwagon. A lot of the jobs I see I would be a good
fit want experience using MongoDB (or something similar).

I have been looking to learn them, but having read up on the technologies, I
can't find a reasonable use case for any of them in my own work. One that
would not be equally or better suited to Postgres or MySQL (which I know
well).

I have come to the conclusion that 90% of people using NoSQL don't actually
need it, and are throwing away a lot of useful features just so they can play
with the latest fad.

~~~
merry-year
NoSQL DBs have real advantages - e.g. you have a huge production relational
DB, you want to make schema changes - you have to take your app offline for
hours.

~~~
Denzel
No. You can migrate big production relational DBs with much less than hours of
downtime; sometimes there's no downtime at all. Please, either qualify your
statement, or stop speaking in such an absolute sense.

~~~
spiffytech
Would you mind expanding on how to minimize downtime when applying migrations
to large DBs? It's clear the grandparent isn't familiar enough with the
relevant techniques to realize their statement needed qualification, or could
count as "nonsense", so they could probably benefit from the explanation.

~~~
Denzel
Sure, it can be accomplished in a variety of ways: swapping a migrated
replica; breaking big schema changes into multiple incremental migrations that
minimize the amount of time the database is locked and back-filling data; or
spinning up an entirely new cluster, migrating everything, and then switching
traffic over from the old cluster to the new cluster at the load balancer. Any
number of these techniques can be mixed and matched to accomplish minimal
and/or zero downtime depending on your constraints. [1] The most important
thing is making sure your application code is able to operate with multiple
schema versions.

I used to have a presentation from Facebook where they spoke about their zero-
downtime migration process, but I can't find it, so this SO post [2] will do.
Of course, there's a bunch more information out there to read up on.

[1] [https://www.honeybadger.io/blog/2013/08/06/zero-downtime-
mig...](https://www.honeybadger.io/blog/2013/08/06/zero-downtime-migrations-
of-large-databases-using-rails-postgres-and-redis)

[2] [http://stackoverflow.com/questions/6740856/how-do-big-
compan...](http://stackoverflow.com/questions/6740856/how-do-big-companies-
like-say-facebook-do-migrations-without-having-downtime)

------
habosa
This article did an excellent job verbalizing the incredible feeling of mental
potency one gets when learning to program. When you see that first "Hello,
World!", you are hooked. I still get this feeling whenever I learn a new
platform. When I learned Android I was amazed that I had made a real-life app
run on my phone. When I learned Ruby on Rails I proudly stuck my flag in the
surface of the internet and declared myself ruler of my domain (pun
intentded). When I learned to program an Arduino I felt my code-laden tendrils
inching out into the real world: that light is blinking because I demanded it
do so!

This is why i'd like to teach programming to kids. I really don't care if they
continue with it or ever learn how to do anything useful, I just want to
expose everyone to that feeling of power you can get when you're behind a
keyboard and in front of the right tools. It makes you think you can do
something amazing, and everyone should have a chance to feel that.

~~~
tbomb
It's such a great feeling. My favorite part is how, no matter how long you've
been doing it for, you still get that feeling time and time again.

~~~
lostlogin
That bit is good. Fixing a bug that has haunted you is even better. Everything
I've ever made is pathetically simple, so I can't imaging how good it must
feel to fix something that is actually complicated.

------
ameister14
For me the thing I had to learn was commenting more than anything else;
working alone I never saw as much use for it. Then I worked with a guy that
commented his code very well and suddenly I saw massive value in it.

I'm definitely still an intermediate programmer, but I think I was always fine
admitting that to myself. It was getting over the fear of others reading and
modifying my code that took me a while.

~~~
nikster
Yeah well...

Great code needs no comments.

Bad code needs lots of comments.

I've seen examples of both recently.

I randomly met a guy who told me of his idea to implement a UX framework with
windows, buttons, views, etc in python.

A week later he sends me the finished framework. And it's perfect. It's easy
to understand, all the names of things make sense, it's orthogonal. Not a
single comment anywhere, but perfectly clear. Great code basically.

And there's a project I am maintaining where some parts of the code are pretty
much impossible to understand, full of duplicated code - somebody loved
copy&paste - duplicated method and class names, and threads going off in all
directions. There is a comment for every line of code but despite the fact
that I consider myself pretty good at reading other people's code, I am not
touching that thing with a 10 foot pole.

My goal is to write code that doesn't require a lot of comments.

~~~
tbrownaw
_Great code needs no comments._

Sure it does.

« The simple and obvious way to do this misses important edge cases X, Y and
Z. »

« This is to work around a bug in the framework we're using; see
[http://..](http://..). . »

« This is deliberately wrong, for compatibility with ABC system. »

------
gedrap
From both my own experience and witnessing others, one major factor that sets
apart from beginner and expert is working with legacy code. And by legacy I
mean legacy from previous developer, previous team, whatever, not necessarily
a decade old code base.

Beginners are keen to get rid of all the legacy code. It's tightly coupled,
it's hard to read, hard to maintain, yada yada yada. And then they tend to
make a way too optimistic estimate on how long it will take. While it might
look like nothing fancy from outside, under the hood it often handles loads of
edge cases etc. Been there, almost done that (didn't fit in the budget which
was way too optimistic already). Eh.

Experienced programmers understand that it's not perfect, but they just live
with that. Surely there are some cases when maintaining the codebase would be
waste of money because the previous coder was a disaster, and sooner or later
it will have to be scrapped away. But it's more tempting to do that than
actually needed.

~~~
nikster
Experienced programmers refuse to take the job.

We once tried to contract this really fancy team to take over some code. They
asked if we had unit tests. "No". "Then we can't do it, sorry, bye."

And I agree with them.

~~~
ufmace
Really fancy, hmm... They strike me as being not very useful if they aren't
willing to touch the code unless it meets some quality standard. I can
understand turning down a contract if the code is total mess and the client
wants major work done in an unrealistic amount of time or for too little
money. In this case, why not reply more like "We're going to have to do some
refactoring before we do X. If your budget allows for that, then we'll take
the job."

------
csense
AFAIK this is actually normal -- you learn the basics from tutorials, then the
things that you need to make more complicated projects easier seem
unnecessary, then you attempt a large project without them, and then you see
why they're necessary.

~~~
sdrothrock
It's normal but can be really, really scary if you don't have a mentor or
someone to help you out or point out some of the pitfalls on the way.

Even something as fundamental as version control is, I think, passed up by a
lot of beginning/intermediate programmers because "it's complicated" and "I
don't need it now because I'm the only one working on this." But a mentor can
help push you into that earlier and walk you through some of the more common
stuff in a more accessible, interactive way than an article or a forum, which
goes a long way.

~~~
esonderegger
What's worked for you all for making the leap from lone programmer to working
on a team with a mentor/people who are smarter than you?

I ask this as someone somewhere between "beginner" and "intermediate". I've
used git on a bunch of projects, but normally get hung up with branches or
with trying to undo changes. Even harder than version control, I think, is
getting a lone beginner programmer to write tests. When I'm writing something,
it's always tricky figuring out exactly what it is I should be testing. When
time is a limiting factor, it's hard to get from "I know I should be doing
this" to actually doing this.

When you are good enough to make your own projects work the way you want them
to work, but not good enough to contribute to the open source projects you
actually use, how do you break out of your bad habits that you know you will
need to break when part of a team/large project?

~~~
mason55
_> When time is a limiting factor, it's hard to get from "I know I should be
doing this" to actually doing this._

If you don't have time to write tests then you've overscoped the features for
the available time. Once you start treating testing as essential and budgeting
a realistic amount of time to write test code (probably on the order of 1:1
feature code time:test code time) then you'll be able to get it done. Your
total number of features will go down but quality will go up.

~~~
esonderegger
I'm sure I'm not the only one who got down the road to overscoped features by
saying "gee, wouldn't it be cool if my users could access this info that's
living in a mysql table" and threw something together with a little php
mysql_query(SELECT...), and it worked! except for some edge cases with non-
ascii characters and the fact that you knew you were opening yourself up to
SQL injection attacks, but you weren't really concerned because you only have
100 users and they're already authenticated by a more robust system. Anyway,
you decide to do it the "right way" and rewrite it using SQLAlchemy. In the
mean time, your coworkers wonder why you've burned half a day rewriting a
feature that worked just fine after you had only been spending 30 minutes on
it.

Sorry, that was a long way of pointing out that us novice programmers often
don't have good methods of determining how long something should take because
we've never done it before.

~~~
DougWebb
_Sorry, that was a long way of pointing out that us novice programmers often
don 't have good methods of determining how long something should take because
we've never done it before._

That is basically the core difficulty in software estimation: none of us have
good methods for determining how long something should take because most of
the time we haven't done it before. If it had been done before in a way we can
reuse, we'd reuse it. The meat of most projects is always something that's in
some way new, even when the new bit is integrating a bunch of pre-existing
parts in a new way.

------
lugg
[http://webcache.googleusercontent.com/search?q=cache:http%3A...](http://webcache.googleusercontent.com/search?q=cache:http%3A//www.michaelbromley.co.uk/blog/65/confessions-
of-an-intermediate-programmer)

------
Bahamut
I've actually been down this route when I was a kid experimenting with making
programs. I did not understand what was the point of functions - why not just
copy/paste blocks of logic?

It wasn't something important to me for a long time since I did other stuff
instead, but coming back to programming in an effort to make a career out of
it, a lot of that stuff became instantly obvious & I felt foolish for not
recognizing it in the first place.

~~~
poopicus
It's funny, as a kid I can remember thinking: "Right, everything has to go in
the main function unless absolutely necessary, it will just be easier to read
that way."

Nowadays, it's the exact opposite!

~~~
doktrin
My code changed in a similar way, however I recently devolved.

I've mostly worked with higher level languages, and recently delved back into
C. I had forgotten what a complete pain in the ass it is to pass complex data
structures around between functions.

I'm a bit ashamed to admit my functions got pretty damn beefy real quick.

~~~
lstamour
Try C++, join the dark side! In addition to chocolate chip cookies, we promise
C++11 move semantics for returned objects/values. The cookies/cake might be a
lie. :-)

~~~
krapp
I had to create a small ADO class for advanced C++ last year.

It was... terrifying.

------
jheriko
There are some absolute, rather than relative measures that you can use to
gauge your skill. For engineering fields (not just software) the 'toolmaker'
analogy is a good one i find. Until you understand what involved in making the
specialist tools you need for your field, and can actually make those tools
yourself then you are far from mastery.

This is not entirely straightforward though - a bit of a rabbit hole you could
say. e.g. should a programmer stop at the compiler? The CPU? The circuitry?
Electronic components? The laws of nature? Tools are built with other tools
after all and some tools are provided by nature...

On the other hand, if you haven't made even the first step towards
understanding your tools then thats not really a problem to worry about.

------
gwern
I found this so striking in part because of recent events: Mark Karpeles's
mother defending him as a genius, Karpeles not delegating coding to
experienced developers and focusing on being a CEO, the leaked PHP MtGox
code...

~~~
encoderer
The bit of leaked PHP code I saw seemed to be reasonably structured?

Now, I wouldn't necessarily use PHP for this sort of work, but...

~~~
lugg
I hope you're not referring to
[http://pastebin.com/W8B3CGiN](http://pastebin.com/W8B3CGiN)

Those 100 line functions wouldn't make it through any half decent code review.
Zero modularization, dal is inextricably linked to almost every piece of logic
in the thing. Its an object called "Bitcoin" and I have a feeling it is 95% of
mt gox' business logic if not all of it, it even writes raw xml to a temp
pointer before dumping it into a cache and then making calls to header().
Separation of concerns? What are concerns?

Sure its tabbed neatly, and its got camelCasing, its using some form of
orm/query thingy going on in there, but its still one hell of an
unmaintainable, untestable mess.

I'd rather a thousand lines of spaghetti than ever having to work on something
like that.

~~~
mml
I once was hired to a gig because of the following words that came out of my
face hole: "Some people see a giant hairball of code, and think to themselves
'I don't want to deal with that'. I see the same code and think 'I'm going to
get a new boat'."

Bad, evil, horrible code written by misguided children makes the world go
around.

~~~
lugg
Pretty much my job description.

~~~
collyw
I hope you get paid well.

------
hippich
I find his experience is very fulfilling. In the beginning he had fun times
doing stuff which actually delivered some results. Probably gradually became
aware of wrong chooses he made and discovered architect side of coding... I
kinda feel this is a way to learn it. I think you need this excitement of fast
moving to keep engaged - it is hacker part of coding. When you are young it is
okey to try something, may be break something and move on.

... Or may be I think like that only because I can see myself almost in every
single line author posted :)

------
encoderer
I agree with the other commenters here. This is part of your development. Yes,
it could've possibly be avoided if you had a CS background or worked alongside
other developers. But it's normal.

When I was still in high school I "invented" inheritance in PHP. I put one
function per file, and used the include search path. When I discovered OO
later I realized what I had done.

It happens :)

------
ritchiea
What are the best ways to get better?

~~~
joeld42
write more code. regret it.

~~~
noonespecial
The scariest place to be as a programmer is when you look back at what you did
6 months ago and still think to yourself that its pretty good. A little regret
is a good, good thing.

~~~
collyw
Five years ago, I would add a new feature and 50% of the time it would be a
fair bit harder than I expected, then maybe 30% of the time I would find it
easier than I expected, as I had designed the code well, and it was set up for
extending / reuse.

Nowadays, I am getting better. If I don't understand a bit of code I wrote a
few months back, then I use it as an opportunity to look at it freshly. Why is
this code crap? Why is it making what I want to do difficult? How could it be
better? That's a good place to start refactoring from.

------
erazor42
Nice article but i was wondering why didn't you go to university/IT School to
learn computer science?

\--

"To me, the object-oriented approach was just a bunch of unnecessary overhead
and boilerplate"

If you had made real C++, you would'nt have think of object oriented
programming as an overhead. I suggest you to buy a few O'Reilly books
(Probably the best code book )

~~~
alexchamberlain
Not the author, but personally, I chose Maths as I felt it gave me a broader
basis to approach my career. I am now happily employed as a Software Engineer.
I do find I've missed out on some things (TDD indoctrination, for example),
but I've gained in others.

~~~
pmr_
There are only very few universities that will actually give you a proper
indoctrination in most modern software engineering practices. Usually you get
a bit of horrible object orientation, a few stern words about coding
standards, and the lovely advice to "always test your code". If you take a
Compilers course chances are the words "static analysis" will be used a lot.

I'm sure there are exceptions to this, but they are hard to find and
universities aren't entirely to blame for it. Some parts of software
engineering move fast and there is a justified fear to teach students things
that will be useless by the time they graduate. So the focus is more on laying
a solid ground-work.

------
justplay
you can access the article from this link in case if isn't opening

[http://webcache.googleusercontent.com/search?q=cache%3Awww.m...](http://webcache.googleusercontent.com/search?q=cache%3Awww.michaelbromley.co.uk%2Fblog%2F65%2Fconfessions-
of-an-intermediate-
programmer&oq=cache%3Awww.michaelbromley.co.uk%2Fblog%2F65%2Fconfessions-of-
an-intermediate-
programmer&aqs=chrome..69i57j69i58.1799j0j4&sourceid=chrome&espv=210&es_sm=91&ie=UTF-8)

------
chrislomax
Although I generally do not post something that is not constructive to an
article, I have to say, I bought the same magazine when I was younger with
Borland on and that is what made me want to become a programmer!

I was amazed when I read that point. The only difference is that I couldn't
get anything to build in Borland. I started out in BASIC making my motherboard
beep to tunes in a BAT file.

------
nollidge
Text-only cache:
[http://webcache.googleusercontent.com/search?q=cache:k4GBqYS...](http://webcache.googleusercontent.com/search?q=cache:k4GBqYSQW8QJ:www.michaelbromley.co.uk/blog/65/confessions-
of-an-intermediate-programmer&hl=en&gl=us&strip=1)

------
V-2
This more or less sums up what I think about "duct tape programmers" (as Joel
Spolsky calls it).

------
dsego
Code Complete is really great. I also recommend Clean Code. I started reading
it before going to sleep, and it got me so excited I couldn't sleep. It was 4
or 5am when I finished it. All I could think about was refactoring all the
code I had ever written.

------
badman_ting
You have to stop thinking about what's good about your work and focus instead
on what sucks about it. Sounds depressing maybe, but that's how you get
better. You can feel good about yourself, or you can get better.

------
jonalmeida
The best part of that post was right under the title..

"File under ego"

------
andystanton
A smashing read. Entertaining and honest, thank you.

------
bitwize
I liked the "Fuck Generator". I've often said that many a programming career
began with this:

    
    
        10 PRINT "COCKS"
        20 GOTO 10

