The Mistakes I Made in My Programming Career
itscommonsensestupid.blogspot.com
itscommonsensestupid.blogspot.com
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.
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.
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.
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. :-)
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.
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 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. 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.
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. :-)
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.
But sometimes the wheel needs to be reinvented, like perhaps the wheel that is available can only be used on a horse driven buggy.
I'm the kind of guy who believes that any (even little) benefit is a reason to reinvent something.
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.
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.