Write code like you just learned how to program(prog21.dadgum.com)
prog21.dadgum.com
Write code like you just learned how to program
http://prog21.dadgum.com/87.html
23 comments
The classic paper 'Worse is better' by Richard P. Gabriel explains this point in a deeper way than this blog entrance.
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.
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.
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.
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.
This is great advice. I often catch myself not writing bad code by not writing any code at all. That's just being chicken.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I think you hit what the author was talking about, which is cranking out code so that it works (for whatever goal, in the case the author describes, user experience), not necessarily so that the code is good.
I learned Japanese, but when speaking it, I'm often hesitant. I used to hang out a lot with native speakers when I was younger, and there seems to be nothing middle-aged Japanese guys love more than seeing young men drink. After a few drinks, you stop second-guessing yourself, and so when speaking, words just came out, and my coworkers began laughing when, after I had spent all day stuttering and pausing, I would start spitting out fluid sentences. (A few more and I became unintelligible again, but for different reasons than hesitance; this was just as amusing to them.)
Coding is the same. Writing a small script, a prototype, or a little program for fun (or on the peak of the "Ballmer curve"), you don't think so much about structure and cleanliness, and you write the minimal amount that gets the job done, even if it's a hairy mess, and leave the editing pass for later (if ever). It's essentially the main tenet of Worse is Better camp and the Agile methodology: make it work as soon as you can.
I've worked at startups and large companies, and at both types of place, I've seen huge codebases, properly engineered and sometimes representing decades of man-hours, get scrapped before launch because they were wrong. I've also seen horrible code that ignored every good idea about building software that survived years. Personally, I have a bunch of code that is embarassing to look at, written as quick hacks, that has survived and done its job for years because it didn't try to understand the problem, just solve it.
Not that structure is bad or that engineering is wrong, but it seems to be independent of a program's survivability and its utility. In fact, Worse is Better seems to produce code that is more adaptable because its structure ignores edge cases that may turn out unimportant in the real world, so when unanticipated but important edge cases come up, the code is less rigid and can be adapted.
I think this lack of second guesses and of worrying about what doesn't matter for the problem at hand is exactly what the author is talking about. In terms of long-term maintenance, a prototype is cheap to build and easy to scrap; if it doesn't get scrapped and replaced, well...there will always be a project that junior programmers can cut their teeth on before subjecting a clean codebase to a kid fresh out of school.
I learned Japanese, but when speaking it, I'm often hesitant. I used to hang out a lot with native speakers when I was younger, and there seems to be nothing middle-aged Japanese guys love more than seeing young men drink. After a few drinks, you stop second-guessing yourself, and so when speaking, words just came out, and my coworkers began laughing when, after I had spent all day stuttering and pausing, I would start spitting out fluid sentences. (A few more and I became unintelligible again, but for different reasons than hesitance; this was just as amusing to them.)
Coding is the same. Writing a small script, a prototype, or a little program for fun (or on the peak of the "Ballmer curve"), you don't think so much about structure and cleanliness, and you write the minimal amount that gets the job done, even if it's a hairy mess, and leave the editing pass for later (if ever). It's essentially the main tenet of Worse is Better camp and the Agile methodology: make it work as soon as you can.
I've worked at startups and large companies, and at both types of place, I've seen huge codebases, properly engineered and sometimes representing decades of man-hours, get scrapped before launch because they were wrong. I've also seen horrible code that ignored every good idea about building software that survived years. Personally, I have a bunch of code that is embarassing to look at, written as quick hacks, that has survived and done its job for years because it didn't try to understand the problem, just solve it.
Not that structure is bad or that engineering is wrong, but it seems to be independent of a program's survivability and its utility. In fact, Worse is Better seems to produce code that is more adaptable because its structure ignores edge cases that may turn out unimportant in the real world, so when unanticipated but important edge cases come up, the code is less rigid and can be adapted.
I think this lack of second guesses and of worrying about what doesn't matter for the problem at hand is exactly what the author is talking about. In terms of long-term maintenance, a prototype is cheap to build and easy to scrap; if it doesn't get scrapped and replaced, well...there will always be a project that junior programmers can cut their teeth on before subjecting a clean codebase to a kid fresh out of school.
I aim for the best of both worlds - blast through the coding when you're at the top of the world; then, once it all works, go back and clean it up and make it pretty. IME, unless you're never ever going to see the code again, it's well worth the time spent.
Of course, not everyone is willing to pay for #2. "It's already done, isn't it?"
:(
Of course, not everyone is willing to pay for #2. "It's already done, isn't it?"
:(
That's what my strategy is. "Get it working, then get it working right, then get it working fast." The "get it working" part is where you start to be able to tell whether or not you've solved the right problem.
I guess it depends on the environment. In a startup, you need results and vision. Even if it costs millions to clean up the mess, you need to get version one out the door. Technical debt is still an issue (sloppy code can cause bugs, and make it harder to iterate), but you don't need the code to be as clean as humanly possible.
In a more stable environment, dirty code will almost certainly come back to haunt you, or your successor. It's not worth 1 man-year to clean up 1 man-year of work, just so you could your job done a little faster. Besider, the pointy-haired manager will push you to speed up, even if it causes more problems later.
In a more stable environment, dirty code will almost certainly come back to haunt you, or your successor. It's not worth 1 man-year to clean up 1 man-year of work, just so you could your job done a little faster. Besider, the pointy-haired manager will push you to speed up, even if it causes more problems later.
For a major undertaking, sure. If you're a start-up, odds are that you have one product, and you can't afford for it to stagnate while it's scrapped and rewritten or while the developers layer hacks on hacks to fix bugs created by the last round of hacks.
Even a start-up, though, has tons of code that is not part of the main codebase. A pile of monitoring scripts, a program that generates an arbitrarily large amount of data for a test database, the company's blog, internal mailing list software, etc. When you have fewer than 50 employees, it is okay if half of those codebases are ugly hacks.
Even a start-up, though, has tons of code that is not part of the main codebase. A pile of monitoring scripts, a program that generates an arbitrarily large amount of data for a test database, the company's blog, internal mailing list software, etc. When you have fewer than 50 employees, it is okay if half of those codebases are ugly hacks.
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.
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.
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]
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.
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.
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=251
http://www.threeriversinstitute.org/blog/?p=252
http://www.threeriversinstitute.org/blog/?p=251
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.
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.
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.
Just build your vision - especially when you're stretching with unfamiliar tools and languages.
Then go back and pay off your technical debt.
Architecture is why we refactor
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.
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.
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.
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.
This is not a strict dichotomy, of course. But it's a dictum well worth remembering.
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.
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.
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.
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.
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!
˚and by program, I guess I just mean building stuff.
Merry Christmas!
It's like having a song idea and learning to play an instrument so you can make it real.
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?
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.
Unlike playing an instrument, programming is not dependend on muscle-memory skills to produce adequate performances, hence repetition is of limited use while studying.
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.
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.
I like ProjectEuler, does that count?
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]
[deleted]
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. :)
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. :)
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.
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.
I disagree with you because in some projects technical correctness is not the first priority. So why should you sacrifice everything in favor of it? In some settings, coding an ad-hoc solution is ugly but better in terms of the constraints (i.e. time, budget) of the project. For example, demos and prototypes.
Also, some programmers don't take satisfaction in writing good code, this article will encourage them to stay in their bad ways, so that's not good. I think this article is good for people who take too much satisfaction in writing good code. Good code is not always an end in itself.
Also, some programmers don't take satisfaction in writing good code, this article will encourage them to stay in their bad ways, so that's not good. I think this article is good for people who take too much satisfaction in writing good code. Good code is not always an end in itself.
I have reviewed or maintained the code of tens of other programmers and came out with your same conclusion. Writing code like that is acceptable if you know exactly what your users want, and you won't need to build any features on top of it.
"...and you won't need to build any features on top of it."
Right. It seems to me that most coding "best practices" are designed to help you maintain and build on your code. The guy who hacked together the animations would be in a world of hurt if his boss came in and said "we need the pool of blood to empty in case A, and in case B, it needs to be water, and in case C, it needs to be a cuddly bunny instead of a skull. Also the animation speed should vary depending on the time of day." This would be even worse if 6 months had passed since the original code was written.
Suddenly, refactoring for flexibility and clarity would sound really, really smart.
Now, if I'm writing a piece of "throwaway" code - say, a script that I'm going to run once to accomplish something, then never use again - I'd agree with "do what works and don't worry how the code looks." But generally, if your code matters to anyone at all, it will need to be tweaked and maintained.
Right. It seems to me that most coding "best practices" are designed to help you maintain and build on your code. The guy who hacked together the animations would be in a world of hurt if his boss came in and said "we need the pool of blood to empty in case A, and in case B, it needs to be water, and in case C, it needs to be a cuddly bunny instead of a skull. Also the animation speed should vary depending on the time of day." This would be even worse if 6 months had passed since the original code was written.
Suddenly, refactoring for flexibility and clarity would sound really, really smart.
Now, if I'm writing a piece of "throwaway" code - say, a script that I'm going to run once to accomplish something, then never use again - I'd agree with "do what works and don't worry how the code looks." But generally, if your code matters to anyone at all, it will need to be tweaked and maintained.
Most software companies end up having at least one person who prototypes or produces proof of concepts. Some have entire teams that prototype (at the behest of the technical pre-sales guys).
The ability to rapidly prototype ideas is extremely valuable. For many early stage founders, a proof of concept is more valuable than a well engineered core product. The PoC gets them the funding, or the first customers.
For most people who have an idea, the PoC should come first, as suggested by the OP. I will agree that there are very few people that can write a PoC with production worthy code. They are real superstars.
Many engineers will knock together PoC before starting to write the main product. When I start out doing that, it's disposable. You throw it away.
Thanks for this guys. I really need to do a PoC so I can recruit some buddies to my idea.
The ability to rapidly prototype ideas is extremely valuable. For many early stage founders, a proof of concept is more valuable than a well engineered core product. The PoC gets them the funding, or the first customers.
For most people who have an idea, the PoC should come first, as suggested by the OP. I will agree that there are very few people that can write a PoC with production worthy code. They are real superstars.
Many engineers will knock together PoC before starting to write the main product. When I start out doing that, it's disposable. You throw it away.
Thanks for this guys. I really need to do a PoC so I can recruit some buddies to my idea.
Just started thinking about all of the "rapid prototyping" environments and languages that I've heard about over 10 years of programming.
There is obviously something to RAD, 4GL, etc. in terms of investigating the problem domain. Sometimes, you have to "just do it" to get clued up.
There is obviously something to RAD, 4GL, etc. in terms of investigating the problem domain. Sometimes, you have to "just do it" to get clued up.
I generally agree with your argument. Well designed code is the best in the end. It's what I aim for.
But I disagree with the implication that one ever reaches an expert stage where one easily balances the conflicting demands of real world program creation.
I don't think I'm original in claim that programming is inherently hard, even compared to other "difficult" tasks. It's hard because a client would prefer you "take on technical debt" (take short-cuts), it's hard because computer programs are among the largest artifact constructed by humans, it's because of the halting problem and any number of factors.
It's hard.
I just had to get that off my chest, OK?
But I disagree with the implication that one ever reaches an expert stage where one easily balances the conflicting demands of real world program creation.
I don't think I'm original in claim that programming is inherently hard, even compared to other "difficult" tasks. It's hard because a client would prefer you "take on technical debt" (take short-cuts), it's hard because computer programs are among the largest artifact constructed by humans, it's because of the halting problem and any number of factors.
It's hard.
I just had to get that off my chest, OK?
Agreed, right after that are idiots who model everything they talked about in the meeting as a class. If I see Manager/Employee classes then I know I'm in for a ride of unmaintainable dreck.
> 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.
That's fine as long as it generated jobs.
This is the broken window fallacy [1]. If the company didn't have to pay developers to maintain bad code, they could invest that money in something more economically useful, like new products.
[1] http://en.wikipedia.org/wiki/Broken_window_fallacy
[1] http://en.wikipedia.org/wiki/Broken_window_fallacy
Unless they went out of business while trying to perfect the code instead of releasing any kind of product.
There is a vast stretch of appropriate solutions between the maintainability hell of "hardcode the coordinates of every pixelchange in your animation" and perfect code.
Absolutely. Let's not fall into false dichotomies here.
Yes, we developers sometimes focus on making the code perfect, beyond the point where there's an actual business case. So we need to be reminded that the code serves the business, not vice versa.
But really. Bad enough code is a liability to the business. You can't add features to make the customers happy, you get bugs you don't understand, it runs really slowly, etc.
The real trick is determining, with an intelligent conversation between developers and business people, what's good enough.
Yes, we developers sometimes focus on making the code perfect, beyond the point where there's an actual business case. So we need to be reminded that the code serves the business, not vice versa.
But really. Bad enough code is a liability to the business. You can't add features to make the customers happy, you get bugs you don't understand, it runs really slowly, etc.
The real trick is determining, with an intelligent conversation between developers and business people, what's good enough.
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.
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]
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.
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.