7 ms·

Confessions of an Intermediate Programmer

257 points by zaidos 13y ago

csense 13y ago
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 13y ago
  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.
  - derekp7 13y ago
    Version control is one of those areas that is very difficult for a lone programmer to understand the need for (I was one). After all, I have backups, right? So why would I need it? Then I hit a snag, where something that worked before somehow didn't work now. And it was a lot harder tracking that down by going through backups, vs doing a git bisect and git revert. Eventually I ended up restoring every backup, and checking them into git.
    - saganus 13y ago
      Same here regarding version control.. until one day I after graduating from college I nostalgically searched for my old college files... and... oh the horror... my files where somewhere between "project1.final_backup_almost_final.java" and "project15.final_not_working.java.backup3" going through more strange things which I can't even think of why I named files like that, along the lines of "epsiloneridani43.final_working_working.tosubmit.java" and of course the project file I ended up sending to the teacher was something like "project16.working_again3.java" ...sigh
      - stephencanon 13y ago
        O to be young and innocent of version control.
      - grey-area 13y ago
        You see a huge amount of this sort of poor-man's version control in other industries - everyone I have worked with in other industries has worked out some personal scheme of versioning using initials, dates, numbering in order to sequence the various states of their work as it passes through multiple people and multiple versions. A lot of room for disruption there I think if someone works out how to make version control fit better with ordinary people's view of the world (i.e. not git, svn etc). Versions in word are the closest I've seen to it but it really shouldn't be in one specific program but in the OS or a helper program.
        ygra 13y ago
        File History in Windows 8 is nice, sort of. It takes snapshots of changed files every hour. Sadly you have to enable it first and it's sort-of treated as a backup (so you have to store the copies on a different volume, etc.). So, not exactly what people have in their home unless they know about such things.
        grey-area 13y ago
        I think the missing solution here though is collaboration and versioning between people, rather than individual backups. Things like File History and Time Machine are nice, but don't really address this need.
      - runiq 13y ago
        To be fair, though, once you get the hang of it, you have to take care not to apply it to everything. Back when I grokked Mercurial (first VCS for me), I used it for packaging scripts, dotfiles, /etc files, todo lists, shopping lists for the grocery store, financial accounting, and my own poor man's dropbox clone (please don't ask). "When you have a ham^H^H^HVCS, everything looks like a programming project".
  - esonderegger 13y ago
    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 13y ago
      > 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 13y ago
        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.
Bahamut 13y ago
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 13y ago
  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!
  - daigoba66 13y ago
    As a kid I wrote a few games using QBasic. I apparently didn't have a firm grasp on control flow because every call to a sub routine ended with a call to another subroutine; sometimes to a sub routine that was already called earlier in the stack. You win the game by beating it before crashing with a stack overflow.
    - Sammi 13y ago
      Nah you just invented continuation passing style. You just needed tail recursion too, and you would be good to go ;)
  - doktrin 13y ago
    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.
    - Nursie 13y ago
gwern 13y ago
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 13y ago
  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 13y ago
    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.
    - farinasa 13y ago
      I personally like the hard coded values and the extremely long line lengths.
      - einhverfr 13y ago
        That was my first thought too. That and "this looks kind of structured from the top but the more I look at it, the less structured it becomes."
    - mml 13y ago
      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.
ameister14 13y ago
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.
- akbar501 13y ago
  I totally agree. When I first started programming my comments largely echo'd the code, so I saw them as less valuable. Now I'm able to stand back from the code and write comments that reflect the "why", and let the code do the talking for the "what / how". I see this a lot where the more experienced someone is the more they comment, but also where the comments are higher quality.
- sliverstorm 13y ago
  It's good you recognized that. In many cases, an intermediate programmer with expert-level group skills (including things like commenting) is worth much more than an advanced programmer with poor group skills. But often people neglect their group skills; they aren't "sexy".
- brianpgordon 13y ago
  I had the opposite experience; I found it easy to scan through comments explaining what the code does, and hard to read the code itself. So I would comment every single thing to explain it in English so that I didn't have to resort to code. Of course I could drop into code mode and rely on logical axioms and learned patterns, but it wasn't as intellectually satisfying as "getting it" with pure intuition. Something similar still serves me well as a general mental framework for approaching programming and debugging at a very local (procedure) level: 1. Make sure that the English language description of the algorithm is logically correct. 2. Make sure the code actually corresponds to the English description.
  - einhverfr 13y ago
    You can take this a little further by separating your comments into two groups: 1. An english language description of what the function (or code block) does as a black box (forget the internals as they are subject to change). What you put in and what you get out, or section headings to structure how you read the code. 2. Comments in the code block to tell you why a given decision was made. What this gives you is the framework you are describing but it further cements it into three layers: 1. Function and block documentation describe contract and what the code is expected to do from outside. If the code does not implement the contract the code is wrong. 2. When reading through the code as contract-implementation you can understand why certain decisions were made. As bonus points, you get good API documentation.
encoderer 13y ago
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 13y ago
What are the best ways to get better?
- joeld42 13y ago
  write more code. regret it.
  - zaidos 13y ago
    In addition to this, reading and being able to understand other people's code will provide great returns. You learn about styling, coding standards, architecture, patterns, etc that you might have never stumbled upon if you attempted to code everything yourself.
    - collyw 13y ago
      That must depend o having decent code to work on in the first place. Seeing some of the comments in the code bases I have worked on, I am not sure I was going to learn anything there.
  - lstamour 13y ago
    To rephrase: write more code. months later, look back at your early code, see if it still makes any sense to you today ;-) rinse, repeat in different languages, situations or version numbers.
  - noonespecial 13y ago
    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.
    - ebiester 13y ago
      It still amazes me that I'm still getting better as a programmer every day, over ten years later. Unfortunately, I repeated the same year of experience in the middle a few times...
lugg 13y ago
http://webcache.googleusercontent.com/search?q=cache:http%3A//www.michaelbromley.co.uk/blog/65/confessions-of-an-intermediate-programmer http://webcache.googleusercontent.com/search?q=cache:http%3A...
akbar501 13y ago
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).
- einhverfr 13y ago
  I hate to sound like an old fogie here (I am almost 40) but one thing that occurs to me is that as we age our thinking changes and all the things you mention often develop over time. When you are 20 you are pretty much at the height of your mathematical abilities. This is fine for certain kinds of programming, but it is not really ideal for others. It ensures that algorithms primary and the domains in a real sense become secondary. As you get older, these tend to flip. You understand the domains better and may not be quite as good at generating optimal algorithms, but the tradeoff is generally positive. Additionally I think there is a tradeoff that happens between dreaming of building great things and developing a craftsmenship approach to the small things. Engineer the small pieces well, and the big pieces will take care of themselves. In most areas, I think one is better with a very mixed-age and mixed-experience team. Older, more experienced programmers bring something very special to the table, but the same is true for younger programmers as well. This being said, I have a few very minor disagreements with you ;-). These may be split hairs though. First, while I rewrite more in some ways, I actually find on the whole I rewrite less because I am not afraid to procrastinate while trying to understand the domain. People wonder why my code seems to come out fully formed and it is because I am not afraid to spend my time thinking about the problem instead of writing a rough draft. What has changed is the sort of rewrites I do. I will typically re-engineer a small piece to remove cruft based on lessons learned from the last two years, rather than rewriting a big piece to meet a new requirement (because things tend to be designed more extensably now). So I am less afraid to rewrite and more willing to do so, but at the same time, I tend to rewrite less. Finally there is the question of optimal way to program. I am of the opinion (probably in part because of how much work I do with Perl) that there is no singular optimal way. Optimal has to be globally defined and one of the jobs of the engineer is to ensure that the framework is optimal so that the team can program optimally. If the team is not part of the definition of what is optimal, then I do agree it is a mess. But I don't think we are dealing with a single dimension here. Understanding the problems the team is struggling with is a good way to ensure that framework can be built in a way that drives that average capability up.
gedrap 13y ago
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.
- gregimba 13y ago
  On the other side if all possible edge cases break it may be time to rewrite your code.
- collyw 13y ago
  I had a nightmare of VB6 code to work on. Something like 3/4 of a million lines, and lots of deadlines to meet. No consideration given to quality - just have it working by friday. It was in the financial industry. On more than one occasion you would write a subroutine to do something, then a month or two later, you would see someone had already written that same functionality.
- nikster 13y ago
  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 13y ago
    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."
deleted 13y ago
[deleted]
jonalmeida 13y ago
The best part of that post was right under the title.. "File under ego"
hippich 13y ago
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 :)
habosa 13y ago
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.
- saraid216 13y ago
  The desire to empower kids is basically one of the best motivations available to everyone. I'd recommend poking around for after school programs where you can volunteer to do it. I spent a month or two teaching HTML to a small group of middle schoolers and it was easily one of my favorite experiences in life.
- tbomb 13y ago
  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 13y ago
    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.
justplay 13y ago
you can access the article from this link in case if isn't opening 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 http://webcache.googleusercontent.com/search?q=cache%3Awww.m...
V-2 13y ago
This more or less sums up what I think about "duct tape programmers" (as Joel Spolsky calls it).
dsego 13y ago
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.
jheriko 13y ago
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.
chrislomax 13y ago
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.
andystanton 13y ago
A smashing read. Entertaining and honest, thank you.
erazor42 13y ago
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 13y ago
  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_ 13y ago
    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.
badman_ting 13y ago
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.
bitwize 13y ago
I liked the "Fuck Generator". I've often said that many a programming career began with this: 10 PRINT "COCKS" 20 GOTO 10
nollidge 13y ago
Text-only cache: 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 http://webcache.googleusercontent.com/search?q=cache:k4GBqYS...

257 points by zaidos 13y ago

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 13y ago
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.
- derekp7 13y ago
  Version control is one of those areas that is very difficult for a lone programmer to understand the need for (I was one). After all, I have backups, right? So why would I need it? Then I hit a snag, where something that worked before somehow didn't work now. And it was a lot harder tracking that down by going through backups, vs doing a git bisect and git revert. Eventually I ended up restoring every backup, and checking them into git.
  - saganus 13y ago
    Same here regarding version control.. until one day I after graduating from college I nostalgically searched for my old college files... and... oh the horror... my files where somewhere between "project1.final_backup_almost_final.java" and "project15.final_not_working.java.backup3" going through more strange things which I can't even think of why I named files like that, along the lines of "epsiloneridani43.final_working_working.tosubmit.java" and of course the project file I ended up sending to the teacher was something like "project16.working_again3.java" ...sigh
    - stephencanon 13y ago
      O to be young and innocent of version control.
    - grey-area 13y ago
      You see a huge amount of this sort of poor-man's version control in other industries - everyone I have worked with in other industries has worked out some personal scheme of versioning using initials, dates, numbering in order to sequence the various states of their work as it passes through multiple people and multiple versions. A lot of room for disruption there I think if someone works out how to make version control fit better with ordinary people's view of the world (i.e. not git, svn etc). Versions in word are the closest I've seen to it but it really shouldn't be in one specific program but in the OS or a helper program.
      - ygra 13y ago
        File History in Windows 8 is nice, sort of. It takes snapshots of changed files every hour. Sadly you have to enable it first and it's sort-of treated as a backup (so you have to store the copies on a different volume, etc.). So, not exactly what people have in their home unless they know about such things.
        grey-area 13y ago
        I think the missing solution here though is collaboration and versioning between people, rather than individual backups. Things like File History and Time Machine are nice, but don't really address this need.
    - runiq 13y ago
      To be fair, though, once you get the hang of it, you have to take care not to apply it to everything. Back when I grokked Mercurial (first VCS for me), I used it for packaging scripts, dotfiles, /etc files, todo lists, shopping lists for the grocery store, financial accounting, and my own poor man's dropbox clone (please don't ask). "When you have a ham^H^H^HVCS, everything looks like a programming project".
- esonderegger 13y ago
  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 13y ago
    > 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 13y ago
      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.

Bahamut 13y ago

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 13y ago
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!
- daigoba66 13y ago
  As a kid I wrote a few games using QBasic. I apparently didn't have a firm grasp on control flow because every call to a sub routine ended with a call to another subroutine; sometimes to a sub routine that was already called earlier in the stack. You win the game by beating it before crashing with a stack overflow.
  - Sammi 13y ago
    Nah you just invented continuation passing style. You just needed tail recursion too, and you would be good to go ;)
- doktrin 13y ago
  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.
  - Nursie 13y ago

gwern 13y ago

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 13y ago
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 13y ago
  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.
  - farinasa 13y ago
    I personally like the hard coded values and the extremely long line lengths.
    - einhverfr 13y ago
      That was my first thought too. That and "this looks kind of structured from the top but the more I look at it, the less structured it becomes."
  - mml 13y ago
    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.

ameister14 13y ago

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.

akbar501 13y ago
I totally agree. When I first started programming my comments largely echo'd the code, so I saw them as less valuable. Now I'm able to stand back from the code and write comments that reflect the "why", and let the code do the talking for the "what / how". I see this a lot where the more experienced someone is the more they comment, but also where the comments are higher quality.
sliverstorm 13y ago
It's good you recognized that. In many cases, an intermediate programmer with expert-level group skills (including things like commenting) is worth much more than an advanced programmer with poor group skills. But often people neglect their group skills; they aren't "sexy".
brianpgordon 13y ago
I had the opposite experience; I found it easy to scan through comments explaining what the code does, and hard to read the code itself. So I would comment every single thing to explain it in English so that I didn't have to resort to code. Of course I could drop into code mode and rely on logical axioms and learned patterns, but it wasn't as intellectually satisfying as "getting it" with pure intuition. Something similar still serves me well as a general mental framework for approaching programming and debugging at a very local (procedure) level: 1. Make sure that the English language description of the algorithm is logically correct. 2. Make sure the code actually corresponds to the English description.
- einhverfr 13y ago
  You can take this a little further by separating your comments into two groups: 1. An english language description of what the function (or code block) does as a black box (forget the internals as they are subject to change). What you put in and what you get out, or section headings to structure how you read the code. 2. Comments in the code block to tell you why a given decision was made. What this gives you is the framework you are describing but it further cements it into three layers: 1. Function and block documentation describe contract and what the code is expected to do from outside. If the code does not implement the contract the code is wrong. 2. When reading through the code as contract-implementation you can understand why certain decisions were made. As bonus points, you get good API documentation.

encoderer 13y ago

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 13y ago

What are the best ways to get better?

joeld42 13y ago
write more code. regret it.
- zaidos 13y ago
  In addition to this, reading and being able to understand other people's code will provide great returns. You learn about styling, coding standards, architecture, patterns, etc that you might have never stumbled upon if you attempted to code everything yourself.
  - collyw 13y ago
    That must depend o having decent code to work on in the first place. Seeing some of the comments in the code bases I have worked on, I am not sure I was going to learn anything there.
- lstamour 13y ago
  To rephrase: write more code. months later, look back at your early code, see if it still makes any sense to you today ;-) rinse, repeat in different languages, situations or version numbers.
- noonespecial 13y ago
  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.
  - ebiester 13y ago
    It still amazes me that I'm still getting better as a programmer every day, over ten years later. Unfortunately, I repeated the same year of experience in the middle a few times...

lugg 13y ago

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

akbar501 13y ago

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).

einhverfr 13y ago
I hate to sound like an old fogie here (I am almost 40) but one thing that occurs to me is that as we age our thinking changes and all the things you mention often develop over time. When you are 20 you are pretty much at the height of your mathematical abilities. This is fine for certain kinds of programming, but it is not really ideal for others. It ensures that algorithms primary and the domains in a real sense become secondary. As you get older, these tend to flip. You understand the domains better and may not be quite as good at generating optimal algorithms, but the tradeoff is generally positive. Additionally I think there is a tradeoff that happens between dreaming of building great things and developing a craftsmenship approach to the small things. Engineer the small pieces well, and the big pieces will take care of themselves. In most areas, I think one is better with a very mixed-age and mixed-experience team. Older, more experienced programmers bring something very special to the table, but the same is true for younger programmers as well. This being said, I have a few very minor disagreements with you ;-). These may be split hairs though. First, while I rewrite more in some ways, I actually find on the whole I rewrite less because I am not afraid to procrastinate while trying to understand the domain. People wonder why my code seems to come out fully formed and it is because I am not afraid to spend my time thinking about the problem instead of writing a rough draft. What has changed is the sort of rewrites I do. I will typically re-engineer a small piece to remove cruft based on lessons learned from the last two years, rather than rewriting a big piece to meet a new requirement (because things tend to be designed more extensably now). So I am less afraid to rewrite and more willing to do so, but at the same time, I tend to rewrite less. Finally there is the question of optimal way to program. I am of the opinion (probably in part because of how much work I do with Perl) that there is no singular optimal way. Optimal has to be globally defined and one of the jobs of the engineer is to ensure that the framework is optimal so that the team can program optimally. If the team is not part of the definition of what is optimal, then I do agree it is a mess. But I don't think we are dealing with a single dimension here. Understanding the problems the team is struggling with is a good way to ensure that framework can be built in a way that drives that average capability up.

gedrap 13y ago

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.

gregimba 13y ago
On the other side if all possible edge cases break it may be time to rewrite your code.
collyw 13y ago
I had a nightmare of VB6 code to work on. Something like 3/4 of a million lines, and lots of deadlines to meet. No consideration given to quality - just have it working by friday. It was in the financial industry. On more than one occasion you would write a subroutine to do something, then a month or two later, you would see someone had already written that same functionality.
nikster 13y ago
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 13y ago
  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."

deleted 13y ago

[deleted]

jonalmeida 13y ago

The best part of that post was right under the title.. "File under ego"

hippich 13y ago

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 :)

habosa 13y ago

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.

saraid216 13y ago
The desire to empower kids is basically one of the best motivations available to everyone. I'd recommend poking around for after school programs where you can volunteer to do it. I spent a month or two teaching HTML to a small group of middle schoolers and it was easily one of my favorite experiences in life.
tbomb 13y ago
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 13y ago
  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.

justplay 13y ago

you can access the article from this link in case if isn't opening 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 http://webcache.googleusercontent.com/search?q=cache%3Awww.m...

V-2 13y ago

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

dsego 13y ago

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.

jheriko 13y ago

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.

chrislomax 13y ago

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.

andystanton 13y ago

A smashing read. Entertaining and honest, thank you.

erazor42 13y ago

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 13y ago
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_ 13y ago
  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.

badman_ting 13y ago

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.

bitwize 13y ago

I liked the "Fuck Generator". I've often said that many a programming career began with this: 10 PRINT "COCKS" 20 GOTO 10

nollidge 13y ago

Text-only cache: 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 http://webcache.googleusercontent.com/search?q=cache:k4GBqYS...