5 ms·

The Mistakes I Made in My Programming Career

13 points by nsoonhui 17y ago

lincolnq 17y ago
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 17y ago
  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.
jacquesm 17y ago
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.
- nostrademons 17y ago
  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.
  - ramchip 17y ago
    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.
- 10ren 17y ago
  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. :-)
  - ThinkWriteMute 17y ago
    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.
  - known 17y ago
    http://en.wikipedia.org/wiki/Pygmalion_effect http://en.wikipedia.org/wiki/Pygmalion_effect
  - jacquesm 17y ago
    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.
- roundsquare 17y ago
  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.
zurcociremer 17y ago
Mistakes, not experiences, are what makes us better programmers.
selven 17y ago
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 http://en.wikipedia.org/wiki/Flood_fill) algorithm and then the next day I found something 20 times faster on Wikipedia.
ThinkWriteMute 17y ago
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 17y ago
  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 17y ago
    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 17y ago
    Sometimes the wheel needs to be reinvented, because, say the old design was patented. Or closed sourced.
- GeneralMaximus 17y ago
  Upvoted. 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.
  - ThinkWriteMute 17y ago
echaozh 17y ago
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.
dkersten 17y ago
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.

13 points by nsoonhui 17y ago

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 17y ago
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.

jacquesm 17y ago

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.

nostrademons 17y ago
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.
- ramchip 17y ago
  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.
10ren 17y ago
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. :-)
- ThinkWriteMute 17y ago
  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.
- known 17y ago
  http://en.wikipedia.org/wiki/Pygmalion_effect http://en.wikipedia.org/wiki/Pygmalion_effect
- jacquesm 17y ago
  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.
roundsquare 17y ago
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.

zurcociremer 17y ago

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

selven 17y ago

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 http://en.wikipedia.org/wiki/Flood_fill) algorithm and then the next day I found something 20 times faster on Wikipedia.

ThinkWriteMute 17y ago

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 17y ago
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 17y ago
  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 17y ago
  Sometimes the wheel needs to be reinvented, because, say the old design was patented. Or closed sourced.
GeneralMaximus 17y ago
Upvoted. 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.
- ThinkWriteMute 17y ago

echaozh 17y ago

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.

dkersten 17y ago

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.