
The Mistakes I Made in My Programming Career - nsoonhui
http://itscommonsensestupid.blogspot.com/2009/11/mistakes-i-made-in-my-programming.html
======
jacquesm
It's funny how the author seems to think that after 5 years he can summarize
the mistakes he has made in his programming career, somehow that suggests to
me that either the career is now over or that there will be no more mistakes
from now on

Whereas the 'exposure' the author has had to me would qualify this person as a
trainee programmer, certainly not someone that can look back at a 'career' of
any significance. Give it another 15 or 20 years and we'll talk. And if you
still remember any of these (other than 'reinvent the wheel', which is in some
ways the worst thing you can do except for those times when it is the best)
then you haven't had much of a career :)

Best of luck, and I hope you will make many more mistakes, these are not on a
'I should blog about this' level yet.

They're more like introductory level mistakes that you could have for the most
part avoided without too much work.

5 years is a long time for only 7 mistakes, I've been doing this for a while
and I'm happy if I get through the day without at least double that figure ;)

to program: verb, telling a computer what you thought you meant.

~~~
10ren
I'm irritated by your negativity. :-) He's admitting his mistakes and he's
making progress. These are good things. If you don't like it, you can just
ignore it, like the rest of the vast internet. Why take special care to put
down _this_ bit of the internet?

In your longer career, I'm sure you've learnt more profound things from your
mistakes. Why don't you share those mistakes and what you learnt (or link to
them if you already have)? If you don't, you are not as good as the blogger
you are criticizing... If your own standards are so high that you don't think
you yourself are yet at a 'I should blog about this' level yet, I'm sure
you're wrong. Others could learn from you; and you'd learn from understanding
and articulating your mistakes.

About his "Too much documentation" point: In a simple recursive descent
parser, I've javadoc-commented each function with its production. Yet even
this _minimal_ documentation gets out of date... I think the right solution
here is code that reads the productions directly, so it becomes self-
documenting - and it stays in sync automatically. :-) (lex/yacc etc etc etc
aren't appropriate for this project). I think this kind of approach is the
ultimate solution to the documentation problem, but it's a lot of work to
create the right tools.

 _EDIT_ One purpose of my project is to do that (i.e. read productions), but I
wasted a couple of months trying to make it self-hosting (as Alan Kay
suggests, and smalltalk and lisp do) before I'd solved the fundamental
problems. Better to address the fundamentals one by one, in isolation, instead
of trying to make it do everything at once. That's something I learnt.

BTW: No offence meant, just happily challengingly provocatively yours, in
solidarity. :-)

~~~
jacquesm
I try to tell others about my lessons from the past and I try to be as
specific as I can, check my posting history for some examples.

Currently working on a piece about online credit card processing and
everything that goes in to that, writing something like that takes time and
effort, not some half hour blog posting.

What bothers me most about these 'mistakes' is that while most of them are
common mistakes the solutions provided send readers off in to the woods. I can
imagine someone with a 5 year career to come up with a lot more substantial
stuff than this, essentially the author shows a pretty myopic view of what
programming is all about and has learned a few very superficial lessons and in
my opinion provides the wrong answers to lessons learned.

I could pick it apart point-by-point but I think that should serve as enough
warning if you're relatively new to this stuff and you read this like it is a
piece of profound insight.

~~~
10ren
Thanks for replying.

Your first comment didn't mention that he provided the wrong answers (most of
it was about the word "career"). They seem (to me) to be common issues, and he
mostly has the right idea. Rather than pick it apart point-by-point, could you
pick just _one_ point he's wrong on?

When a person makes disparaging generalizations, it sounds like they have
prejudged the work, without reading it (why waste time reading it - they
_know_ it's bad). Maybe you're right, but it's hard to tell if you give only
judgment and no evidence. Therefore I ask "can you elaborate please?" :-)

BTW: I followed your suggestion, and found this excellent comment of yours
about pitching to VCs (<http://news.ycombinator.com/item?id=866299>), and I
agree a lot of time and effort went into it. So I stand corrected on that
issue, and my apologies for suggesting otherwise! :-) (though I'm sure much
more blood sweat and tears went into the getting of your experience than in
the writing - maybe that's true for the blogger too?)

aside: it's weird - I upvoted, but your comment is still at 1 point... I've
seen this happen before when I upvote a reply to me. It may be a bug, perhaps
related to downvotes being disabled on replies to one's own comments.

PS: this exchange made me think about my own mistakes. They are very specific
to my area, and then to be against the received wisdom (e.g. Alan Kay above).
But it's not immediately clear to me what my mistakes have been, and what I've
learned... it seems like it would be a useful exercise to consider this.

~~~
jacquesm
I think HN drops votes selectively, most of the time it manages to hide the
fact that it does to the voter. Personally I think this is rather childish but
that's the way it works. (In my view if a function doesn't work you simply
drop that part of the interface, not to give the user the impression that
something has been done when in fact it hasn't. This is part of the 'secret
sauce' of HN, so maybe the overall effect is positive, but I feel like I'm
being treated like a child.).

About that 'one point':

1) not using a proper ORM:

ORMs have their place. In a project that does 'simple' stuff (ACID style) you
can get away with using the ORMs worldview to get through your day. The
problems start when you have to do stuff that the ORM does not provide for. As
soon as you hit that limitation you're in for a fun ride, mostly because ORM
data models were meant to be accessed through a program writing the queries.
To write queries that do complicated stuff for database tables that have been
created and maintained through an ORM will get you bogged down pretty quickly.
Assuming that you are even allowed to do so. So to thoroughly research the use
cases for your data before committing to a specific ORM can save you a lot of
time later.

In general I think this is a problem that relatively inexperienced programmers
face, they pick the first tool that _seems_ to cover all the bases and start
working on the code, only to run out of steam somewhere halfway in to the
project, by that time you've got a lot of effort invested in to that
particular solution and to abandon it gets harder with every minute that you
further invest.

The fact that the author has re-written this particular chunk of code 3 times
now and still isn't satisfied is telling, the lesson to learn here is not 'use
a proper ORM', the lesson as far as I can see it is 'research your work before
committing to your tools'.

Experience will teach you that requirements change, they change all the time,
there has never been a project of any magnitude that did not have its
requirements change over the course of its deployment, and as a rule this
already surfaces during development.

So you plan ahead, you build for the future, not for the simplistic view you
have today. It will save you lots of money and time later, your first rewrite
then is a decade off instead of a few months.

The rest of the 'mistakes' listed suffer from similar shortcomings in their
'lessons learned'.

That is why I have a problem with this posting, not because it is bad to learn
from your mistakes.

I think this guy should work together with more experienced people that can
guide him in the right direction, rather than to assume that because he's
making some slow progress (5 years ??!) he is now in a position to present his
wisdom.

~~~
10ren
I upvoted and checked immediately, and you're right: it presents an upvote in
the JS interface, but a reload reveals the truth. Not counting reply upvotes
does prevent long, mutual karma-generating exchanges, but if it's trying to
disguise that reality from users it isn't very effectively disguised. I'm not
100% convinced it's deliberate, but it could be, like that idea of making
trolls invisible, but not letting them know they are invisible (not sure how
that's applicable here, maybe so people don't explore trickier ways of getting
karma)

I agree that ORMs are good for the basic impedance mismatch, but are hard to
optimize for more complex queries. I do wonder if working directly with the
database is becoming a dark art, as most practitioners would prefer to avoid
it if possible, and they often can.

"So you plan ahead, you build for the future, not for the simplistic view you
have today." So you disagree with those agile ideas of "you ain't gonna need
it" and "release early, release often". You're describing something like the
waterfall model. I'm actually not against the waterfall model, it's just that
you need to have done a few similar projects to have the requisite level of
judgment, like a carpenter building his 10th kitchen. Most practitioners
aren't at this level of expertise - they'll still learning what the _problem_
is. If they try to do what you suggest without your level of experience,
they'll _really_ make a mess. It's a matter of a novice knowing that they
don't know.

I agree that working with experienced folk would help, but such folk are in
short supply (though possibly many people are reluctant to find them, and
would rather be the "experts" themselves - maybe this is what you find
objectionable).

I guess he could have gained much more experience in 5 years, if he had done
several database projects over that period, instead of improving just the one.

~~~
jacquesm
Re. the voting, that's deliberate, PG is on the record about that. I thought
it was a bug and reported it as such, he assured me that it was not, but that
he was experimenting with deciding which votes to count.

re. software development:

Agile is great for web development, for projects that have a short life cycle
and that are not going to be around 10 years from now in a way that you can
relate back to your original design spec.

But not everything is web development (which is more closely related to
evolution than to design), not every project has a short life-cycle.

If you are in lets say the banking business, where software routinely outlives
its creators you have to have a completely different view of things.

Like everything else, agile is a tool that has its uses but it shouldn't be
the only tool that you've got or know how to use.

~~~
10ren
Good perspective on different length of life-cycles; some areas repay careful
investment; some don't.

I've found many of the common wisdoms don't quite apply to what I'm doing (in
some ways it's analogous to DB's relational model; it's experimental,
theoretical and practical)... and so my hard-won lessons aren't applicable to
other areas.

Thanks for your thoughtful and kind replies. :-)

------
dkersten
I'm not saying this to undermine the article or suggest that I'm in any way
more experienced or knowledgeable (I'm probably not) - nor am I disagreeing
(at least, not with all of it) and certainly not saying this as advice to
others, but heres my, personal, responses to these points:

 _Not using a proper ORM_

I solved this one by switching to a NoSQL database. Fancy ORM? Bleh, too
complex, brittle, hassle, whatever - schema free databases let me store my
objects however I like and give me other (potential) benefits too, like
MongoDBs sharding, replication, nicely parallel map/reduce etc. I also free
myself from having to come up with _future proof_ schemas (or emulating a
schema free database with complex tables).

 _Not learning generics soon enough_

While I agree with this, I think it misses another issue: over-reliance on the
OO paradigm. By only using OO when it actually makes sense and using other
abstractions when it doesn't (streams, trees, lists, tables, relationships,
immutable state, whatever), I've achieved even more generic software
components and reusable code than generics would give me and also
(potentially) gained other advantages too (better abstractions for reasoning
about my solution, clearer code, better concurrency...)

 _Reinvent the wheel_

If you're reasonably new to programming (or even just a single language or
paradigm or domain), the only excuse to reinvent the wheel is as a learning
experience. At this stage, you don't have enough experience to write your own
production ready version. No excuses. Later, though, I think there are times
when its appropriate to reinvent the wheel and at this point you should have
enough experience to recognize them, but even then, I imagine its rare.

 _Too much documentation_

Unfortunately hes right.. which is problematic, because not documenting isn't
the answer either. Having self-documenting code is important, but ultimately
won't help user-of-your-api (who may never get a chance to review the code to
figure out what it does) as much as some _real_ documentation.. Anyone whos
ever had to code with only some standards committees spec knows how fun this
is... Same goes for having only an API reference available - great if you
already know how everything works together and need.. a reference.. useless if
you have no idea how anything works yet.

 _No automated build_

I totally agree with this. I often don't use automated builds for my own
projects, but once they get in any way complex, I write at least a shell
script to make this easier.

 _Rely on visual inspection and debugging too much_

You can never do enough to ensure your code is as good as it can be..
unfortunately costs mean you have to draw the line somewhere and leave it be.
Debugging and visual inspection aren't proactive enough to ensure quality and
theres a large amount of things that can be done to try and minimize error,
but at the end of the day, its likely not quite enough and you'll end up
debugging anyway.. :-(

 _No unit test_

I agree here too. One of the techniques to help above. Also helps protect when
refactoring and helps minimize wasted effort.

------
ThinkWriteMute
I simply hate people who think reinventing the wheel is bad. If we hadn't
reinvented the wheel then the wheel would still be a horse.

~~~
bugs
How would it be a horse? Reinventing the wheel refers more to reproducing a
tool that already exists with little to no benefit.

But sometimes the wheel needs to be reinvented, like perhaps the wheel that is
available can only be used on a horse driven buggy.

~~~
ThinkWriteMute
Sure on a purely dictionary scale "reinventing the wheel" means to reproduce a
tool that exists with little to no extra benefit. More often than not, however
it's used to down play the achievements or ideas of others.

I'm the kind of guy who believes that any (even little) benefit is a reason to
reinvent something.

------
echaozh
I think if someone fails to provide a means to automatically build his code
after his first year in the profession cannot be considered as competent.

Even if the means is to use an IDE is better than nothing.

For a prototype of 1 or 2 source files, maybe manually compiling everything is
still acceptable. After that, the first thing to do is to write a Makefile, or
anything like that. It's definitely the highest priority.

------
selven
I totally understand the concept of not reinventing the wheel. Reminds me of
the time when I was overjoyed at the fact that I figured out how to implement
a flood filling (<http://en.wikipedia.org/wiki/Flood_fill>) algorithm and then
the next day I found something 20 times faster on Wikipedia.

------
lincolnq
Meh. Looks like this guy should've taken an intro software engineering course
and read a little Joel Spolsky instead of taking 5 years to learn this.

~~~
selven
There's no substitute for experience. There's a difference between knowing
that x,y and z are bad and understanding why they are bad from personal
experience.

------
zurcociremer
Mistakes, not experiences, are what makes us better programmers.

