8 ms·

Write code like you just learned how to program

222 points by angrycoder 16y ago

notmyname 16y ago
Obviously, a new programmer's code will not be as good as an experienced programmer's. I think the important lesson here is to "write code". "like you just learned how to program" modifies "write", not the code. I found myself in the same position as the author. As I was going through a CS program, I thought back to my early years of writing code. Sure, those early programs didn't have computationally optimal algorithms or the current {design pattern|algorithm|language} of the week, but they were fun, and I got stuff done. Once I graduated, and now that I've been coding professionally for nearly 8 years, I find that the best way to keep that passion about code and not get encumbered by "how it's supposed to be done" is to read other peoples' code and work with really smart people who encourage you to be a better developer.
- _delirium 16y ago
  Yeah, I definitely agree with this. Knowing a lot more about software than when I was a middle-school/high-school kid makes me a better programmer, but vastly increases the startup energy. When I wrote mIRC scripts to do something I wanted my client to do, or some Perl scripts to maintain my Home Page, the startup energy was nearly zero, and I didn't think about alternative technologies, architectures, the "right" way to do things, APIs, extensibility, etc. I just wrote some hackish thing, then when I couldn't extend it any more, I rewrote parts to fix it. Ugly and unmaintainable, but time-to-ship was like a day. I guess the trick is combining some aspects of those approaches. I find it hard to do: it's now so obvious to me when I'm writing ugly and unmaintainable code that's Not Doing It Right that it's almost painful to make myself do it anyway.
chrismealy 16y ago
This is great advice. I often catch myself not writing bad code by not writing any code at all. That's just being chicken.
- wccrawford 16y ago
  There's no shame in that. It's called "fear" and can be overcome by research or just forging ahead blindly. I prefer the research method. It's a lot slower, but I feel much better about the results when I get there.
Autre 16y ago
Well, i'm not sure about that. Aren't we expected to be professionals and act like ones on any given job? Should we just eschew Knuth and express ourselves? Don't think so. OTOH, it seems like something is clearly wrong here since, we are having a tough time being professional and working with the current crop of languages, tools, technologies, etc and in the same time, fully expressing our vision while enjoining our work.
- Someone 16y ago
  IMO, the text is not about personal expression, but about "Le mieux est l'ennemi du bien." ("the better is the enemy of the good"; Voltaire), aka "real artists ship" (Jobs) Most beginning programmers will see few, if any, bears on the road ahead of them. That makes it easier for them to just move to the goal line. Of course, good expert programmers will be able to see which bears actually are on the road, and plan for evading them, and not any other bears.
- hardy263 16y ago
  Interesting contrasting view. And you are right, we should be professionals. But on the other hand, if you consider it as a project triangle approach, you're given "Well-designed UI, maintainable code, cheap: pick two" And as professionals, we want to express our clients' vision as much as possible, so we have to make a balance between having good code and the budget that the client gave us. It's not really the fault of our tools and technologies, but we do try to continually improve those tools so that we can provide the best service.
dasil003 16y ago
The author here is talking about the importance of plowing ahead with a vision, but the title initially made me think of something else. Now that I've been programming for over a decade professionally, I've accumulated a lot of practical experience. On balance this makes me a better programmer, but it also makes me worry more about everything: maintenance, bugs, version upgrades, etc. Wrestling with all possible issues can be paralyzing. Often it's better to just get something done, even if your future self will claim how much better it have been if it was done "right" in the first place.
- leftnode 16y ago
  I know that feeling well: it's what makes me hesitant from time to time to learn new technology. I think about all of the domain experience I would immediately not have. When I first started I didn't know what I didn't know and thus just dove right in.
  - shade 16y ago
    This is exactly what I'm dealing with, too. I keep wanting to learn Ruby/Rails (and I have been working my way through the Rails Tutorial book online, albeit with a break the last week or so for travel and stuff). At the same time, I keep thinking "You know, I have so much domain experience with C# and ASP.NET, so would it be a better use of my time to focus on learning ASP.NET MVC and improving my architectural skills?" I'm still working through that, but in the mean time, I'm pushing myself to at least go through the Rails tutorial (and probably an all-day Rails session at the CodeMash precompiler day) on the grounds that it's probably a good thing for me to break out of my narrow MS tech focus and gain exposure to other ways of doing things. I think the only real constant in this field is that if you're not continually learning something, you're falling behind.
    - seer 16y ago
      I think it is very important to learn a few different technologies from time to time - they often expose you to various concepts you haven't heard of before. My personal experience with Rails (reading the source code itself and that of its plugins) was that I got so many ideas how to do stuff that transfered quite well to my other projects. It happens so often that after I switch technologies, and then return after awhile I have a "wow it is so much easier to do it this new way" feel. Creative thinking is fundamentally a "combine and use old stuff in a new way", which means that learning new technologies is worth it just because of the new ideas, and if you can later use those technologies themselves - well thats just a bonus. Anyway, the original comment is right on the money. I often have to tell miself "just write the damn stuff and refine it later" when I get mentally stuck thinking about ways in which it could break.
marcamillion 16y ago
This advice has been my experience building my app. I have a CS degree, but I never did much programming after - I went more into product management. However, now that I am building my own app, I have forced myself to learn the entire stack (from Rails to JS and beyond). I sometimes look at other people's code and compare what they did in 1 line, to what I did in a block of 10 lines and wonder when I will be able to write elegant code like that. But I have learned to console myself, that at the end of the day, for this first release, it doesn't matter what the code looks like. Just so long as it isn't slow and the user has a good experience (i.e. things behave the way they expect it to), then I am doing a good job. The perfectionist in me hates leaving it like that (I want to refactor every chunk until it is completely optimized), but the realist in me knows that I only have X amount of time to complete. Thanks for posting this, because now I don't feel like I am doing a major disservice to my users by programming like the n00b I am.
ScottBurson 16y ago
There's a major exception that needs to be stated here. If you're writing anything with security implications -- anything that handles users' valuable personal data, particularly financial -- you had damn well better know what you're doing and think about it carefully. If your site gets hacked and credit cards get stolen, your users will have a crappy experience, no matter how spiffy your site is otherwise.
deleted 16y ago
[deleted]
tmcneal 16y ago
Sometimes when I'm in 'idea mode' I like to just plow ahead and get something running even if the code is crappy. It gives me a chance to see the idea in action. I then go back and re-implement the idea with the appropriate code structure, unit tests, etc. My first pass is really about proving out the idea, learning about the domain, and finding any gotchas. The second pass is about using my experience from the first pass to create a clean, maintainable base.. something that I can come back to in a month and be able to maintain, enhance, and deploy without having to relearn everything again.
DanielRibeiro 16y ago
Kent Beck, the creator of XP, mentioned something really similar a couple of months ago on his "Flight of a startup" posts: http://www.threeriversinstitute.org/blog/?p=252 http://www.threeriversinstitute.org/blog/?p=252 http://www.threeriversinstitute.org/blog/?p=251 http://www.threeriversinstitute.org/blog/?p=251
jellicle 16y ago
In any creative endeavor, the largest barriers to completion are internal. The creator gets tired, loses interest, and never completes the vision. The author is saying that getting something out is better than having a beautiful, difficult, half-completed and abandoned lump. It's really the same admonition as the ones to build the minimum viable product, or not to worry about premature optimization. Don't do work that isn't necessary! Every bit of unnecessary work increases the chance of total failure. In the early stages, your biggest obstacle is getting SOMETHING, ANYTHING, out and working. We tell writers: sit down and write. We should tell programmers: sit down and program. Well, stand, if you don't want your back to ache.
coolgeek 16y ago
Architecture is why we refactor. Just build your vision - especially when you're stretching with unfamiliar tools and languages. Then go back and pay off your technical debt.
- Confusion 16y ago
  Architecture is why we refactor I sincerely disagree with this point of view. To me, 'architecture' consist of exactly all those aspects of an application that you can not change by a mere refactoring. There are parts of an application's design that are much harder to change, after the fact, than others. If you've built your Japanese pagoda from wood and rice-paper and you decide afterwards you're really going to need a concrete foundation and some central steel columns to tie your pagoda to it, you're basically going to have to rebuild it.
Fluxx 16y ago
Understanding that a "concise, fast, scalable and maintainable" code is not always superior to "complex, slow, unscalable and unmaintainable" code is a big learning for me over the years. There are tons of "web developers" out there who know some PHP and are charging clients with real money to write really, really bad code for their exotic plants website. They can write their crappy code because they're the only developer and they're only working on some random exotic plants website that gets 500 visitors a day and has 2 database tables with 50 rows. Not that big of a dal. At that point it doesn't matter if they don't have indexes in their tables or know what indexes even are. The single developer is cheap to hire and for the most part get the job done. Clients are happy, developer is happy. Where code like the skull dripping blood or the exotic plants website breaks down is when you try to extend the codebase, scale it or handle more users. It's going to fall flat on its face and you're likely going to have to start over or refactor large portions of the code. That does happen sometimes, but at that point you probably understand your problem domain enough to know what the right features are and rewrite it anyways. So it's not always a bad thing. But when you do the rewrite, you should hire the people who know what they're doing and can write "concise, fast, scalable and maintainable" code.
- raganwald 16y ago
  Complex, slow, unscalable and unmaintainable code in a shipping product beats a concise, fast, scalable and maintainable unfinished design. This is not a strict dichotomy, of course. But it's a dictum well worth remembering.
danielrhodes 16y ago
From reading some of these comments, it seems like a few people have missed the point the author was trying to make. The point was not to write better code or to write code fast, it was that a 'good' programmer is focused on writing better code, not on what the user ends up seeing/experiencing (which at the end of the day is the important part). In the author's case, he focused on the wrong thing and ended up with a comparatively boring looking animation, despite having superior code.
juddlyon 16y ago
Reminds me of the "Curse of Knowledge" written about in Built to Stick. Example: while working on a client's app, I spent two hours cobbling together a jQuery plugin to vertically align some dynamic navigation (sometimes the labels were one line, other times two or three). The project manager walked up and in five seconds said: "I made a website a while ago, I think you can vertically align table cells." Three minutes later, the nested table worked perfectly.
marcos123 16y ago
Whoa, I'm really glad I read that. I've always had this lingering worry that my being completely new to coding, and my tendency to learn by doing instead of reading a book... any book, would surely prevent me from finding success. It's just really easy to get sucked into coding. The first thing anyone wants to do is learn how to make text a certain color or size, and then from a little CSS, everything is like a perfect stepping stone. HTML to PHP to Python. And even then, it's possible to get by on only coding what you need to, if you start with a good cms. So... I guess what I'm saying here is although I am glad and it's great that coding "like you just learned how to program" can be an asset, but if it's actually so easy to be one of those people that just learned how to program˚, shouldn't everyone be a little more worried about competition than they are? I know I feel a bit of a burning sensation under my ass each time I manage to cobble something awesome together, with 99% being someone else's freely available code and 1% being mine. ˚and by program, I guess I just mean building stuff. Merry Christmas!
cturner 16y ago
It's like having a song idea and learning to play an instrument so you can make it real. This is a good analogy, perhaps better than the author realises. The way we learn to program tends to be nothing like the way music is taught, but it would be more effective if it were. Just as it's important to be able to nail scales through repetition, it's valuable to be able to type effortlessly, and to enter in patterns without thinking. Think of programmers who - when confronted by a linked list scenario - mindlessly hammer in what's needed. Repetitive drilling of those patterns is a good mechanism for improving programming skill. Yet we tend not to think about learning programming this way. Think of that time recently where you struggled to get something working, and now when you need the pattern you just copy-and-paste from there. How many of us can reliably hammer out a socket server interface without it causing any cognitive load?
- jarin 16y ago
  The only problem with that approach is it's REALLY BORING and a lot of people won't get through it. I think a better way to learn programming is to go through a Zen-like process where you learn how to make something, then go through the rigorous process once you understand WHY you need to learn these things, THEN go back to making stuff.
- brandnewlow 16y ago
  That's how I learned the guitar. I'd write tunes on the piano and hear a guitar part. I would get friends to play them for me but it was a hassle so I took two months worth of lessons and am now able to hear, map out and then play simple guitar leads and rhythm parts. My programming approach has been similar.
- mdonahoe 16y ago
  I like ProjectEuler, does that count?
- adrianN 16y ago
  I don't think that would be a very effective way of teaching. The hard part of programming is usually not writing things like linked lists, but the ability to decompose a real world problem into sufficiently small parts that can be solved by writing down some common patterns. Repetitive learning of patterns won't help at all with developing this skill and may very well scare off students because it becomes boring very quickly. Unlike playing an instrument, programming is not dependend on muscle-memory skills to produce adequate performances, hence repetition is of limited use while studying.
motters 16y ago
This sounds as if he's in favour of the skull programmer's output. I've seen the skull methodology used in practice in businesses, and it invariably results in disaster (i.e. angry bosses/employees and disappointed or fleeing customers). If your code is unmaintainable it may be ok for a brief demo, but beyond that it only causes grief.
- deleted 16y ago
  [deleted]
deleted 16y ago
[deleted]
markkat 16y ago
This was nice to read. I am teaching myself to program at the moment, just so I can build MVPs of some of the ideas I have. I doubt I'll ever be a great programmer, but that's not really my goal anyway. I only hope to build something that needs to be rebuilt due to scaling problems. :)
edw519 16y ago
It's extremely difficult to be simultaneously concerned with the end-user experience of whatever it is that you're building and the architecture of the program that delivers that experience. Maybe impossible. Layperson who's never seen it: "Impossible" Practitioner who's becoming better: "Extremely difficult" Expert: "We do this all the time. What's the big deal?" I think the only way to pull it off is to simply not care about the latter. Write comically straightforward code, as if you just learned to program, and go out of your way avoid wearing any kind of software engineering hat--unless what you really want to be is a software engineer, and not the designer of an experience. I know that OP meant well, but I think this is about the worst advice I've ever seen here. A little background... I have reviewed or maintained the code of thousands of other programmers, and I've encountered maybe a couple dozen I'd actually hire and about 5 I'd consider as technical co-founders. What's the biggest difference? Until today, I wasn't sure how to verbalize, but now, I think a good description would be those who appear to take OP's advice and those who know better... AFAIC, there's is a close correlation between good code and user experience. There's a close correlation between readable code and maintainable code. There's a close correlation between expertise and precision to detail throughout. And perhaps most of all, there's a close correlation between something built properly to stand the test of time and long term user satisfaction. If you want to learn a hobby, develop a passion, or really dig deep, by all means, follow OP's advice and just code it. Sometimes that's simply the best way to understand what goes on under the hood and learn what's possible once you learn the right way to build things. Once you learn the right way to build things. But, please, please, please, leave your experiments on your own hard disk where they belong. You may have thought that those bleeding pixels were cool, but your name will be cursed by the poor souls who forever have to maintain your mess.
- mathgladiator 16y ago
  > your name will be cursed by the poor souls who forever have to maintain your mess. That's fine as long as it generated jobs.
  - yesno 16y ago
    Depends where. In the US? poor souls kept getting blamed by management. IT is expensive says Management. So they offshore. Job is gone. Once industry sang the same song, we're done. No more IT practitioners in the US. The shift is happening right now and it happens in a similar fashion: nobody feels it yet but suddenly the rug under them is gone one day. Silicon Valley is an exception. There are always great companies like Apple and Google. And there are those poor startups that try to overwork the so-called "energetic, genius, creative" fresh-grads. But the turn-over/turn-around rate is very high. Stick long enough in this industry and we'll start seeing patterns.
deleted 16y ago
[deleted]
mks 16y ago
I think what could be taken from article is: write simple code. However it does not entitle you to write sloppy code. Often naive algorithms and shortcut solutions work great. But make them so that when you actually need to replace them you just unplug them and replace with something better.
Shorel 16y ago
The classic paper 'Worse is better' by Richard P. Gabriel explains this point in a deeper way than this blog entrance.

222 points by angrycoder 16y ago

Obviously, a new programmer's code will not be as good as an experienced programmer's. I think the important lesson here is to "write code". "like you just learned how to program" modifies "write", not the code. I found myself in the same position as the author. As I was going through a CS program, I thought back to my early years of writing code. Sure, those early programs didn't have computationally optimal algorithms or the current {design pattern|algorithm|language} of the week, but they were fun, and I got stuff done. Once I graduated, and now that I've been coding professionally for nearly 8 years, I find that the best way to keep that passion about code and not get encumbered by "how it's supposed to be done" is to read other peoples' code and work with really smart people who encourage you to be a better developer.

_delirium 16y ago
Yeah, I definitely agree with this. Knowing a lot more about software than when I was a middle-school/high-school kid makes me a better programmer, but vastly increases the startup energy. When I wrote mIRC scripts to do something I wanted my client to do, or some Perl scripts to maintain my Home Page, the startup energy was nearly zero, and I didn't think about alternative technologies, architectures, the "right" way to do things, APIs, extensibility, etc. I just wrote some hackish thing, then when I couldn't extend it any more, I rewrote parts to fix it. Ugly and unmaintainable, but time-to-ship was like a day. I guess the trick is combining some aspects of those approaches. I find it hard to do: it's now so obvious to me when I'm writing ugly and unmaintainable code that's Not Doing It Right that it's almost painful to make myself do it anyway.

chrismealy 16y ago

This is great advice. I often catch myself not writing bad code by not writing any code at all. That's just being chicken.

wccrawford 16y ago
There's no shame in that. It's called "fear" and can be overcome by research or just forging ahead blindly. I prefer the research method. It's a lot slower, but I feel much better about the results when I get there.

Autre 16y ago

Well, i'm not sure about that. Aren't we expected to be professionals and act like ones on any given job? Should we just eschew Knuth and express ourselves? Don't think so. OTOH, it seems like something is clearly wrong here since, we are having a tough time being professional and working with the current crop of languages, tools, technologies, etc and in the same time, fully expressing our vision while enjoining our work.

Someone 16y ago
IMO, the text is not about personal expression, but about "Le mieux est l'ennemi du bien." ("the better is the enemy of the good"; Voltaire), aka "real artists ship" (Jobs) Most beginning programmers will see few, if any, bears on the road ahead of them. That makes it easier for them to just move to the goal line. Of course, good expert programmers will be able to see which bears actually are on the road, and plan for evading them, and not any other bears.
hardy263 16y ago
Interesting contrasting view. And you are right, we should be professionals. But on the other hand, if you consider it as a project triangle approach, you're given "Well-designed UI, maintainable code, cheap: pick two" And as professionals, we want to express our clients' vision as much as possible, so we have to make a balance between having good code and the budget that the client gave us. It's not really the fault of our tools and technologies, but we do try to continually improve those tools so that we can provide the best service.

dasil003 16y ago

The author here is talking about the importance of plowing ahead with a vision, but the title initially made me think of something else. Now that I've been programming for over a decade professionally, I've accumulated a lot of practical experience. On balance this makes me a better programmer, but it also makes me worry more about everything: maintenance, bugs, version upgrades, etc. Wrestling with all possible issues can be paralyzing. Often it's better to just get something done, even if your future self will claim how much better it have been if it was done "right" in the first place.

leftnode 16y ago
I know that feeling well: it's what makes me hesitant from time to time to learn new technology. I think about all of the domain experience I would immediately not have. When I first started I didn't know what I didn't know and thus just dove right in.
- shade 16y ago
  This is exactly what I'm dealing with, too. I keep wanting to learn Ruby/Rails (and I have been working my way through the Rails Tutorial book online, albeit with a break the last week or so for travel and stuff). At the same time, I keep thinking "You know, I have so much domain experience with C# and ASP.NET, so would it be a better use of my time to focus on learning ASP.NET MVC and improving my architectural skills?" I'm still working through that, but in the mean time, I'm pushing myself to at least go through the Rails tutorial (and probably an all-day Rails session at the CodeMash precompiler day) on the grounds that it's probably a good thing for me to break out of my narrow MS tech focus and gain exposure to other ways of doing things. I think the only real constant in this field is that if you're not continually learning something, you're falling behind.
  - seer 16y ago
    I think it is very important to learn a few different technologies from time to time - they often expose you to various concepts you haven't heard of before. My personal experience with Rails (reading the source code itself and that of its plugins) was that I got so many ideas how to do stuff that transfered quite well to my other projects. It happens so often that after I switch technologies, and then return after awhile I have a "wow it is so much easier to do it this new way" feel. Creative thinking is fundamentally a "combine and use old stuff in a new way", which means that learning new technologies is worth it just because of the new ideas, and if you can later use those technologies themselves - well thats just a bonus. Anyway, the original comment is right on the money. I often have to tell miself "just write the damn stuff and refine it later" when I get mentally stuck thinking about ways in which it could break.

marcamillion 16y ago

This advice has been my experience building my app. I have a CS degree, but I never did much programming after - I went more into product management. However, now that I am building my own app, I have forced myself to learn the entire stack (from Rails to JS and beyond). I sometimes look at other people's code and compare what they did in 1 line, to what I did in a block of 10 lines and wonder when I will be able to write elegant code like that. But I have learned to console myself, that at the end of the day, for this first release, it doesn't matter what the code looks like. Just so long as it isn't slow and the user has a good experience (i.e. things behave the way they expect it to), then I am doing a good job. The perfectionist in me hates leaving it like that (I want to refactor every chunk until it is completely optimized), but the realist in me knows that I only have X amount of time to complete. Thanks for posting this, because now I don't feel like I am doing a major disservice to my users by programming like the n00b I am.

ScottBurson 16y ago

There's a major exception that needs to be stated here. If you're writing anything with security implications -- anything that handles users' valuable personal data, particularly financial -- you had damn well better know what you're doing and think about it carefully. If your site gets hacked and credit cards get stolen, your users will have a crappy experience, no matter how spiffy your site is otherwise.

deleted 16y ago

[deleted]

tmcneal 16y ago

Sometimes when I'm in 'idea mode' I like to just plow ahead and get something running even if the code is crappy. It gives me a chance to see the idea in action. I then go back and re-implement the idea with the appropriate code structure, unit tests, etc. My first pass is really about proving out the idea, learning about the domain, and finding any gotchas. The second pass is about using my experience from the first pass to create a clean, maintainable base.. something that I can come back to in a month and be able to maintain, enhance, and deploy without having to relearn everything again.

DanielRibeiro 16y ago

Kent Beck, the creator of XP, mentioned something really similar a couple of months ago on his "Flight of a startup" posts: http://www.threeriversinstitute.org/blog/?p=252 http://www.threeriversinstitute.org/blog/?p=252 http://www.threeriversinstitute.org/blog/?p=251 http://www.threeriversinstitute.org/blog/?p=251

jellicle 16y ago

In any creative endeavor, the largest barriers to completion are internal. The creator gets tired, loses interest, and never completes the vision. The author is saying that getting something out is better than having a beautiful, difficult, half-completed and abandoned lump. It's really the same admonition as the ones to build the minimum viable product, or not to worry about premature optimization. Don't do work that isn't necessary! Every bit of unnecessary work increases the chance of total failure. In the early stages, your biggest obstacle is getting SOMETHING, ANYTHING, out and working. We tell writers: sit down and write. We should tell programmers: sit down and program. Well, stand, if you don't want your back to ache.

coolgeek 16y ago

Architecture is why we refactor. Just build your vision - especially when you're stretching with unfamiliar tools and languages. Then go back and pay off your technical debt.

Confusion 16y ago
Architecture is why we refactor I sincerely disagree with this point of view. To me, 'architecture' consist of exactly all those aspects of an application that you can not change by a mere refactoring. There are parts of an application's design that are much harder to change, after the fact, than others. If you've built your Japanese pagoda from wood and rice-paper and you decide afterwards you're really going to need a concrete foundation and some central steel columns to tie your pagoda to it, you're basically going to have to rebuild it.

Fluxx 16y ago

Understanding that a "concise, fast, scalable and maintainable" code is not always superior to "complex, slow, unscalable and unmaintainable" code is a big learning for me over the years. There are tons of "web developers" out there who know some PHP and are charging clients with real money to write really, really bad code for their exotic plants website. They can write their crappy code because they're the only developer and they're only working on some random exotic plants website that gets 500 visitors a day and has 2 database tables with 50 rows. Not that big of a dal. At that point it doesn't matter if they don't have indexes in their tables or know what indexes even are. The single developer is cheap to hire and for the most part get the job done. Clients are happy, developer is happy. Where code like the skull dripping blood or the exotic plants website breaks down is when you try to extend the codebase, scale it or handle more users. It's going to fall flat on its face and you're likely going to have to start over or refactor large portions of the code. That does happen sometimes, but at that point you probably understand your problem domain enough to know what the right features are and rewrite it anyways. So it's not always a bad thing. But when you do the rewrite, you should hire the people who know what they're doing and can write "concise, fast, scalable and maintainable" code.

raganwald 16y ago
Complex, slow, unscalable and unmaintainable code in a shipping product beats a concise, fast, scalable and maintainable unfinished design. This is not a strict dichotomy, of course. But it's a dictum well worth remembering.

danielrhodes 16y ago

From reading some of these comments, it seems like a few people have missed the point the author was trying to make. The point was not to write better code or to write code fast, it was that a 'good' programmer is focused on writing better code, not on what the user ends up seeing/experiencing (which at the end of the day is the important part). In the author's case, he focused on the wrong thing and ended up with a comparatively boring looking animation, despite having superior code.

juddlyon 16y ago

Reminds me of the "Curse of Knowledge" written about in Built to Stick. Example: while working on a client's app, I spent two hours cobbling together a jQuery plugin to vertically align some dynamic navigation (sometimes the labels were one line, other times two or three). The project manager walked up and in five seconds said: "I made a website a while ago, I think you can vertically align table cells." Three minutes later, the nested table worked perfectly.

marcos123 16y ago

Whoa, I'm really glad I read that. I've always had this lingering worry that my being completely new to coding, and my tendency to learn by doing instead of reading a book... any book, would surely prevent me from finding success. It's just really easy to get sucked into coding. The first thing anyone wants to do is learn how to make text a certain color or size, and then from a little CSS, everything is like a perfect stepping stone. HTML to PHP to Python. And even then, it's possible to get by on only coding what you need to, if you start with a good cms. So... I guess what I'm saying here is although I am glad and it's great that coding "like you just learned how to program" can be an asset, but if it's actually so easy to be one of those people that just learned how to program˚, shouldn't everyone be a little more worried about competition than they are? I know I feel a bit of a burning sensation under my ass each time I manage to cobble something awesome together, with 99% being someone else's freely available code and 1% being mine. ˚and by program, I guess I just mean building stuff. Merry Christmas!

cturner 16y ago

It's like having a song idea and learning to play an instrument so you can make it real. This is a good analogy, perhaps better than the author realises. The way we learn to program tends to be nothing like the way music is taught, but it would be more effective if it were. Just as it's important to be able to nail scales through repetition, it's valuable to be able to type effortlessly, and to enter in patterns without thinking. Think of programmers who - when confronted by a linked list scenario - mindlessly hammer in what's needed. Repetitive drilling of those patterns is a good mechanism for improving programming skill. Yet we tend not to think about learning programming this way. Think of that time recently where you struggled to get something working, and now when you need the pattern you just copy-and-paste from there. How many of us can reliably hammer out a socket server interface without it causing any cognitive load?

jarin 16y ago
The only problem with that approach is it's REALLY BORING and a lot of people won't get through it. I think a better way to learn programming is to go through a Zen-like process where you learn how to make something, then go through the rigorous process once you understand WHY you need to learn these things, THEN go back to making stuff.
brandnewlow 16y ago
That's how I learned the guitar. I'd write tunes on the piano and hear a guitar part. I would get friends to play them for me but it was a hassle so I took two months worth of lessons and am now able to hear, map out and then play simple guitar leads and rhythm parts. My programming approach has been similar.
mdonahoe 16y ago
I like ProjectEuler, does that count?
adrianN 16y ago
I don't think that would be a very effective way of teaching. The hard part of programming is usually not writing things like linked lists, but the ability to decompose a real world problem into sufficiently small parts that can be solved by writing down some common patterns. Repetitive learning of patterns won't help at all with developing this skill and may very well scare off students because it becomes boring very quickly. Unlike playing an instrument, programming is not dependend on muscle-memory skills to produce adequate performances, hence repetition is of limited use while studying.

motters 16y ago

This sounds as if he's in favour of the skull programmer's output. I've seen the skull methodology used in practice in businesses, and it invariably results in disaster (i.e. angry bosses/employees and disappointed or fleeing customers). If your code is unmaintainable it may be ok for a brief demo, but beyond that it only causes grief.

deleted 16y ago
[deleted]

deleted 16y ago

[deleted]

markkat 16y ago

This was nice to read. I am teaching myself to program at the moment, just so I can build MVPs of some of the ideas I have. I doubt I'll ever be a great programmer, but that's not really my goal anyway. I only hope to build something that needs to be rebuilt due to scaling problems. :)

edw519 16y ago

It's extremely difficult to be simultaneously concerned with the end-user experience of whatever it is that you're building and the architecture of the program that delivers that experience. Maybe impossible. Layperson who's never seen it: "Impossible" Practitioner who's becoming better: "Extremely difficult" Expert: "We do this all the time. What's the big deal?" I think the only way to pull it off is to simply not care about the latter. Write comically straightforward code, as if you just learned to program, and go out of your way avoid wearing any kind of software engineering hat--unless what you really want to be is a software engineer, and not the designer of an experience. I know that OP meant well, but I think this is about the worst advice I've ever seen here. A little background... I have reviewed or maintained the code of thousands of other programmers, and I've encountered maybe a couple dozen I'd actually hire and about 5 I'd consider as technical co-founders. What's the biggest difference? Until today, I wasn't sure how to verbalize, but now, I think a good description would be those who appear to take OP's advice and those who know better... AFAIC, there's is a close correlation between good code and user experience. There's a close correlation between readable code and maintainable code. There's a close correlation between expertise and precision to detail throughout. And perhaps most of all, there's a close correlation between something built properly to stand the test of time and long term user satisfaction. If you want to learn a hobby, develop a passion, or really dig deep, by all means, follow OP's advice and just code it. Sometimes that's simply the best way to understand what goes on under the hood and learn what's possible once you learn the right way to build things. Once you learn the right way to build things. But, please, please, please, leave your experiments on your own hard disk where they belong. You may have thought that those bleeding pixels were cool, but your name will be cursed by the poor souls who forever have to maintain your mess.

mathgladiator 16y ago
> your name will be cursed by the poor souls who forever have to maintain your mess. That's fine as long as it generated jobs.
- yesno 16y ago
  Depends where. In the US? poor souls kept getting blamed by management. IT is expensive says Management. So they offshore. Job is gone. Once industry sang the same song, we're done. No more IT practitioners in the US. The shift is happening right now and it happens in a similar fashion: nobody feels it yet but suddenly the rug under them is gone one day. Silicon Valley is an exception. There are always great companies like Apple and Google. And there are those poor startups that try to overwork the so-called "energetic, genius, creative" fresh-grads. But the turn-over/turn-around rate is very high. Stick long enough in this industry and we'll start seeing patterns.

deleted 16y ago

[deleted]

mks 16y ago

I think what could be taken from article is: write simple code. However it does not entitle you to write sloppy code. Often naive algorithms and shortcut solutions work great. But make them so that when you actually need to replace them you just unplug them and replace with something better.

Shorel 16y ago

The classic paper 'Worse is better' by Richard P. Gabriel explains this point in a deeper way than this blog entrance.