I don't want to be a Real Programmer
verybadalloc.com
I don't want to be a Real Programmer
1–10 of 90 posts
Re: I don't want to be a Real Programmer
#2Time. Work. Those two things are the only things that can deliver on your aspirations. By your definition I'm a real programmer, and yet after well over 20 years programming I'm still humbled by what I don't know.
There's so much I could write here about where to focus (focus on a real problem, forget about agile or lean, focus on the joy of the moment, worry less about whether you chose the right stack), but I've got work to do...
I will leave you with one thought - every time I finished a project badly I learnt something profound that was scarily relevant in the next project, and made that next project successful. It's that continuous motivational cycle that's so addictive.
Re: I don't want to be a Real Programmer
#3great essay. ime, the best programmers are equal part artist and hacker. but, the synthesis would be impossible to describe or even recognize by most non-programmers. and: conversations about their abandoned or unrealized projects are sometimes more interesting than their completed ones.
Re: I don't want to be a Real Programmer
#4Well attended a JS conf last year and I got to be at the same room as TJ Holowaychuk. I had no idea who the guy was and ended up asking where he came from, what he works with, etc. Shame on me haha.
Re: I don't want to be a Real Programmer
#5Its interesting to hear from someone who's more of a hobbyist programmer. You don't meet so many, mainly I think because once you become half-decent at programming you have access to a range of well paid jobs. Of course as you say, those jobs come with certain conditions that aren't for everybody.
I've often thought of quitting professional programming and it to become a hobby instead. I think sometimes great things come from playing around and working on projects you want to and enjoy working on as opposed to the 'drudgery' of implementing someone else's vision. In my experience although the job has its perks, very few 'real' programmers actually care much about the products they work on. Sometimes they do when they start but it doesn't take long for the pressure of getting something done vs. getting something done you have real pride in generally breaks you eventually.
At the end of the day I think if you can write some code, you are a programmer, whether you are a hobbyist or not. Some of the best developers hack on open source projects and live off very little and they're pretty happy with their lifestyle. A lot of paid-up programmers are in fact more like 'impostors' than these guys.
Re: I don't want to be a Real Programmer
#6In my experience there are two kinds of programmers. Those who program (largely based upon practices they are told are good) and those who also really think about their own programming and try to develop their own paradigms in response to their own problems.
The latter tend to be, in the long run, far more productive than the former. However, this takes both motivation and it takes extra time between iterations to think about what problems you are having with development and how to solve them. Continuous iterations get in the way of it, but it isn't clear that the heavy engineering waterfall model gets people to do it either.
Sometimes you need some distance so you can come back and ask "is this good code? What can I do better?" Without distance, it is like editing your own essays.
After 10 years of coding professionally and over 20 years of programming experience, I find that that capacity, which is entirely independent of how many hours someone actually spends coding, is the best indication of how productive someone will be.
If I am ever hiring programmers, my questions won't be puzzle questions. They will be questions like "how do you decide what needs testing?" or "when and why do you comment your code?" Those questions are likely to tell me more about how much someone has thought about their own code experiences than whether they can solve a certain puzzle or not.
Re: I don't want to be a Real Programmer
#7Time. Work. Those two things are the only things that can deliver on your aspirations. By your definition I'm a real programmer, and yet after well over 20 years programming I'm still humbled by what I don't know. There's so much I could write here about where to focus (focus on a real problem, forget about agile or lean, focus on the joy of the moment, worry less about whether you chose the right stack), but I've go…
There do seem to be a lot of rather "precious" induhviduals coming into the industry these days who seem to easily get obsessed with trivial stuff whilst missing the bigger picture.
Re: I don't want to be a Real Programmer
#8> Since I started about 3 years ago
Let's get some perspective here. If you were an undergrad you'd just be about to graduate. Nobody would expect you to be particularly good at programming at this stage -- your career is literally just beginning!
Re: I don't want to be a Real Programmer
#9It seems the OP is trying to compare himself with the internet. We may hear about great achievements every day, but often those achievements while only taking minutes to read about took years or even decades of work and labor and were hardly achieved by one person alone.
A Real Programmer is simply one who keeps on learning and doing. It is important to look back occasionally on what you have achieved, instead of what you have not.
Re: I don't want to be a Real Programmer
#10In my experience there are two kinds of programmers. Those who program (largely based upon practices they are told are good) and those who also really think about their own programming and try to develop their own paradigms in response to their own problems. The latter tend to be, in the long run, far more productive than the former. However, this takes both motivation and it takes extra time between iterations to th…
The distance thing is the best way to improve your own code in my opinion. I have a medium sided codebase to look after. When I have not touched a bit for a few months and I need to go back, it should make sense to me very quickly (I wrote it after all). If it doesn't I ask myself why it doesn't and what I would expect to find to make it more understandable. Then refactor from there. Its too easy to be focused on the details of a piece of code, and not see the bigger picture. That's why being away from a piece of code gives me the best opportunity to evaluate it objectively.