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.
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. :-)
Learning from your mistakes is fine. Telling others what you learned is fine. Learning the wrong things from your mistakes is fine. Telling others the wrong things you learned from your mistakes and passing them off as truths is bad.
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.
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.
It's not that they're wrong so much as that they're incomplete. The author has a very CRUDscreen/.NET/VisualStudio-oriented worldview, and his tips apply to that but probably won't be applicable generally. If you're working at Google, for example, an ORM is probably the last thing you'll reach for. And if you're working in an agile web-shop with RoR, generics are utterly useless.
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.
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.
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.
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.
That was my first impression too, but I wonder if we're being a little bit too uncharitable. Retrospectives like this have value, even if it's mostly just for the person doing the retrospective.
Also, most of these mistakes are pretty broad, philosophical statements. It can take a while to discover that you're on the wrong track with something like this. I'm guessing that if he keeps at it for another 15 or 20 years, he'll do another 2-3 complete reversals on each of these positions as he realizes the world is a lot more complicated than it seems at first. I know I have, and I've only been at it for 5 years.
One thing that struck me: his career seems totally optimized for the "custom business app, database-backed CRUDscreen" programmer. Which IMHO is a pretty boring subfield to optimize for, but different strokes for different folks. I think his perspective would be a lot broader if he did heavy algorithmics (a la Google or finance) or startups, though.
One thing that struck me: his career seems totally optimized for the "custom business app, database-backed CRUDscreen" programmer.
I think that's the problem. ORM and generics are very specific things to me, not something I'd see as a long-term lesson to keep in mind. His programming experience seems very .NET/Visual Studio-centric. Programming in other paradigms might make his point about eg. unit tests more mitigated.
People with longer careers generally have a lot more to say about mistakes, but I tend to find that the advice they give is often very general. I was happy to see that these were much more specific suggestions.
Unless you know roughly what the layers of abstraction your app build on are doing, you're going to have a very tough time getting anything done. What better way to learn how compilers work than by writing a throwaway compiler yourself? In the end, you're going to be a better judge of existing tools because you will know, roughly, what they're doing inside that black box.
Of course, for production level code, reinventing the wheel is the worst thing you can do -- unless you can prove that your particular realization of the wheel is better than what already exists.
If people did not reinvent wheels all the time, our wheels would still be round blocks of stone.
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.
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.
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.
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.
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.
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.