7 ms·

You're a Bad Programmer. Embrace It.

75 points by Garbage 16y ago

devmonk 16y ago
Great post! Some suggestions that were new to me, too, although you're mixing Java and Ruby in your examples. I agree with everything except the DSL stuff at the end. People have mentioned on HN recently, and I believe it is true, that Cucumber, etc. may be something customers get involved with in the beginning, but then they lose interest in it. Sure there are a number of other things that vary from place to place like politics, conformance to standards, etc. But, customers typically just want to see results (in a reasonable amount of time). If you spend time on good design/UI/UE (read "nice looking and easy to use"), it is fast, it doesn't break, and you've tweaked to their needs, you're set.
- JaredRichardson 16y ago
  I've spent more time in Ruby and Java than other languages. My background is leaking through. :) Feel free to post any other tools to the comments on the article. Re: DSLs... I don't think the DSL specs always stay in front of the customer (they sometimes do), but they're a valuable tool. Whether it's a developer, a technical customer, or a non technical customer, you've provided a much simpler way to show what the system does. That's a huge win. I also find that developers who spend time in DSLs tend to write much cleaner code. Once you get used that level of abstraction, you use it in other places.
kahawe 16y ago
This simple and completely true statement never ceases to fascinate me: > In short, as an industry, we all stink. We really do stink and we as an industry are nowhere near a state where there are any real standards and best practices in place like e.g. when building a skyscraper or a road. Those are fairly to pretty damn complicated tasks and there is so much knowledge, experience and best practice involved and everyone in the construction industry (should..) knows them and when it is done you can have it checked and certified that it was well built and won't crumble the next day. I don't think anything like this even remotely exists in IT. We have a lot of RFCs describing protocols and what not but nobody can really objectively certify your serious-business software as well-built or can verify whether you applied even the smallest best practices or common sense guidelines because there are so many almost religious wars being fought over completely minor advantages and dis-advantages which simply do not matter on a global scale. And far too many really, really actually bad programmers just get away with their mess or horrible, insane code.
- twymer 16y ago
  I think the use of some of these strategies mentioned are what should be best practice. Code coverage checkers and code analysis tools, most specifically.
- mechanical_fish 16y ago
  We need to remember that computers are young. Really, really young. The invention of the first-ever electronic digital computer is still an event within living memory. This can be hard to remember. Especially when you yourself are young, you're used to thinking of things that are even slightly older than you as eternal. (When you reach my age, and you are beginning to have colleagues who literally weren't alive during formative periods of your early career, you get a deeper appreciation for the fact that people -- including yourself -- have these horizons.) For example, I did graduate work on lasers, and I built my work on top of a great deal of earlier work, so I tend to think of lasers as things that have been around for a long time. But the laser isn't very old. It turned fifty this year. Many of my friends are older than the laser. Many of its early pioneers are still wandering around. Look up the early years of engineering. Read certain chapters of the excellent Structures, or Why Things Don't Fall Down, or for a more personal view check out Chapter 20 of Mark Twain's Life on the Mississippi: http://www.classicreader.com/book/2886/21/ http://www.classicreader.com/book/2886/21/ The early history of tall buildings is the history of towers falling down. The early history of modern bridges is the history of bridges collapsing. The early history of steam-powered transportation is the history of boiler explosions, especially in the USA, which had a reputation for quick-and-dirty mechanical hacks as far back as the early 19th century. These situations took decades to change... or longer. Sometimes an order of magnitude longer. And, crazy ideas about the Singularity notwithstanding, technology proceeds at a human pace. Right now, we're still at the point where substantial portions of the world population don't even have access to a computer (although the smart phone promises to change that). Very few people know how to program at any level. And that is the major issue facing programmers today, as it has been since the microcomputer was invented in the 1970s: There is more value in spreading the temporary hacks around more widely and cheaply than there is in inventing more permanent and solid stuff. Until we can meet the insatiable and growing demand for poor implementations of 1970s-era computing technologies, there's really no time or money for anything else. This condition is probably temporary, but when I say "temporary" I may still be talking on the scale of decades.
Tichy 16y ago
I am struggling with that: how to market myself as a consultant, knowing that all code sucks?
- twymer 16y ago
  Just remind your clients that your code sucks less than your competitors.
  - mgkimsal 16y ago
    Indeed, knowing that things suck and being able to document why they suck, and why your approach is somewhat better is a good skill. It's not all smoke and mirrors - it's providing a somewhat objective assessment of the situation. I provide unit tests and documentation for projects - many others don't. Well... showing that to a client and saying "you're getting this which will help you understand what I'm doing, and help future devs understand what I did" is just good sense. If the client values it, they will pick you over someone else. If they don't value it, they will after they choose the cowboy over you . :)
- access_denied 16y ago
  This is a strategic decision your clients have to make. So basically it comes down to you wanting a) talking to clients about these issues 'consulting' or b) not talking about these issues. What do you want? Which working env is what your business should be to you? If you are ok with talking about these issues to your clients, you should set it up in a way that let's you charge consulting fees for all the talking. Then you can take your time and educate about code quality and what it means for your clients if they buy bad code. The alternative is of course to work only on projects where you are the only coder A-Z. (Maybe I can write a more helpful text, if you make your question a bit more clearer.)
- patio11 16y ago
  "I made X several million dollars." Why talk about code?
  - 16y ago
jasonlotito 16y ago
It reminds me of the saying (probably butchered here) that the more we learn about a topic, the more we realize how little we really know.
twymer 16y ago
The article starts of a little depressing, telling the reader that humans are bad at programming and we have no hope. At least it finishes telling us we just need to use a bunch of cool toys to look smarter.
argv_empty 16y ago
We can't remember all the methods our code needs to call, so we use autocompleting IDEs to remind us. I thought memorizing all of the details of these was only important in school, and even then only at exam time.
- olavk 16y ago
  I always thought it strange to consider it 'cheating' to rely on a powerful IDE. A programming language is a tool - nobody think it is cheating or a sign of weakness to use the most powerful/productive programming language suitable for a task. An IDE is similarly a tool, which complements the language - just as the code we write is basically a tool.
- regularfry 16y ago
  Not true. If you have the details in your head, you can manipulate and compare them far faster than if you have to rely on an external tool. That means you can rehearse more ideas, faster, which will lead to a better likelihood of picking the best one.
- points 16y ago
  Remembering things is VERY important. It means you have an instant grasp of the code base, the APIs available to you. It means you can solve problems much quicker than someone who only has a limited memory, or uses auto-complete all the time.
  - kenjackson 16y ago
    Remembering the right things is very important. I know the code base far better now with an IDE than I ever did without one. Because it lets me focus on what is really important in the code. I get to focus on code structure, algorithms, I can quickly drill into the code and back out. I can in a few seconds see all uses or all definitions. The thing that makes IDEs great IMO, is when I'm looking at code that isn't mine. The ability to abstract structure from other peoples code quickly is a godsend.
tomlin 16y ago
I've always believed that I am a pretty terrible programmer. I'm cool with that because I know I am gradually becoming better and better each day. I invoke 3 core principals/ideals: * No matter how good you are, someone is always better than you. Yes. Always. * Surround yourself with people smarter than you, rather than shun them egotistically. Intelligence is contagious. * Admit fault, show humility to others who do the same.
edw519 16y ago
Wait, what? OP claims that we are bad programmers because we use too many tools: We can't remember all the methods our code needs to call, so we use autocompleting IDEs to remind us. and then recommends using tools to become better programmers: These tools flag common mistakes... really common mistakes. I know I'm in the minority because I've had this debate with almost every programmer I know, but I do not use an IDE for exactly this reason. I want the "firmware" that knows how to assemble building blocks of code to be in my brain, not in my computer. To me, writing code is like driving a stick shift, for much of it I don't even think, it's unconscious competence. Can you imagine driving a car with auto-complete, color coding, or drop down menus? To this day, I get pissed off when something doesn't compile the first time, usually because of a typo. There's a time and a place for every tool. An IDE or test suite is like a back brace or crutches; they are indispensable when you really need them, but they only weaken you when you're healthy. I guess I draw the line in a different place from OP (and almost everyone else I know).
- RyanMcGreal 16y ago
  >OP claims that we are bad programmers because we use too many tools I took from the essay that the tools we use are evidence of our bad programming ability, not the cause of it. Incidentally, I mainly code in gedit, for much the same reasons you cite.
- DisposaBoy 16y ago
  I dislike IDEs for all their features which for the most part I think just add clutter, since I've ever found a use for most of them like debuggers etc. but I'll admit that they are useful if done right and can bring a productivity boost. When I have to write things like: strstr($str, $delimiter) and explode($delimiter, $str) Netbeans ctrl+p comes in very handy in re-enforcing my choice of arguement order because if I make a mistake that's a very subtle bug waiting to happen. or when I have to wrote things like: g_file_new_for_commandline_arg who wants to type that out when they don't have to? or this over and over: AStudpidlyLongName:: when I can just type `ast` and press ctrl+[space] and get the name in a completion list highlighted every single time. or: m_ui->tooBar->addWidget when I can m_ui.t... and have to automatically figure the correct sequence, this comes in pretty handly when you're working code written by other and they decide to use hard objects as opposed more common pointers.
Maro 16y ago
I'm a good programmer. Embrace it! I used to think I'm a bad programmer, and I was. But ever since I'm doing my startup, I'm concentrating on one project in one language, instead of ten different things in 4 different languages. My co-founder and I found and agreed on a practical subset of the language (C++), and we write great code. I'm still a "bad programmer" in the sense that if I wrote Javascript code, it'd not be great, but now I know that the key to success is to concentrate on one thing for a long time --- and actually it's possible to be a "good programmer" if you do that. Okay, I still don't do enough testing, but in our case (distributed DB) the long-term smart solution is to hire a test engineer..
- deleted 16y ago
  [deleted]
- kls 16y ago
  You sir get a gold star, The big reason that projects fail is "technology soup", everyone has to get their pet project or technology into the project. It gets worse the bigger the projects get. When you get to the enterprise where the big project are, you get governance and a bunch of design by committee. Where people who are not writing the code, tell the people that are "here is what you are going to use". It is funny but every time I walk into a project that is "fad" programming I see failure. When I walk in a see a bunch of guys heads down, iterating and releasing the most crucial features first, the project always seem to succeed. Maybe the solution is less magic technology dust not more.
  - hammerdr 16y ago
    "heads down, iterating and releasing the most crucial features first" That's the key. The "number" of technologies involved is moot. Every piece of software is build upon thousands of layers of technology. Adding one or more ingredients to the soup doesn't necessarily ruin it. Often the simplest way to solve a problem is to duct-tape two different items from different technology stacks just well enough that it works for you. In that simplest case, you may be duct-taping 2 technologies together with a 3rd.
jister 16y ago
A short bio at the bottom of the article says: "Jared Richardson works at Logos Technologies As a recognized expert in the software industry..." Take note of the word EXPERT. He claims developers are bad programmers yet he is an expert. It's contradicting or maybe the right word in the bio should be WORST? :P
- JaredRichardson 16y ago
  Nice catch! It's just marketing though. Don't read too much into that...
JaredRichardson 16y ago
Hi all. I'm a long time lurker, but when I saw my article made the front page, I made an account. :) I don't think that using tools makes us "bad"... I think pretending that we're "good" when we really need the tools make it much more difficult for us to past our egos and really look for what we need. There are so many great practices and tools available, but most developers I've encountered because things are "good enough". I was hoping to encourage people to try something new. Something a "good" programmer would never need, but a "bad" programmer would desperately want. In regards to knowing the API versus using an IDE... spend some time with a Ruby developer. Someone who's not used to having great IDE support. They've been forced to learn the language. The difference in their productivity level is amazing. Contrast them with a developer who only learned Java or dot Net and was using Eclipse or Visual Studio from day one. Those developers tend to not learn the underlying APIs and I think it hurts their ability to know what functionality and libraries are available to them. Anyway, it's very cool seeing an article I wrote on HN!
TamDenholm 16y ago
Personally i dont use an IDE, i use gedit because it does what i want, colour coding, auto indentation and a file browser pane that supports (s)ftp (but i suppose thats actually the OS), thats all i'll ever want or need. If you want to use an IDE, then by all means go ahead, but if your trying to hire me, dont make me use it, and dont make me use an OS i dont like either. Everyone's different and they've got their own way of working, just let them do it their way and they'll be more productive, they'll achieve what you're after.
SanjayUttam 16y ago
While this doesn't necessarily negate the "we can't remember syntax" argument...I remember back before mobile phones were rampant, I was really great at remembering phone numbers. People besides by parents were regularly surprised at how I'd remember numbers I'd seen or read just once. Then I got a mobile phone. I think I probably have less than 5 numbers memorized (those of my immediate family). In essence, using an IDE encourages us not to memorize syntax.
weego 16y ago
Does anyone still believe there are really any ground breaking insights to be made in these kind of self-loathing rhetoric articles? Shouldn't there be more "You know what, sometimes just having something work is pretty much awesome" articles instead of everything fooling themselves that every programmer in the world needs to be a mini-genuis?
known 16y ago
You're a good programmer if you reuse code.
j_baker 16y ago
Am I the only one who feels the whole egoless programming thing has gone too far? Yeah, ego is a bad thing. But self-esteem and confidence aren't. I'm not afraid to say that I feel I'm good at what I do. That doesn't mean I'm never wrong or that I don't make mistakes. It just means I'm proud of my abilities.
reynolds 16y ago
I can't imagine using autocomplete or even an IDE. I remember when I first started I was writing C++ on Windows in Visual C++. My learning only accelerated once I moved off Windows and stopped using autocomplete. Once I started working on Linux and in vim, I didn't even consider looking back. I like to think I'm a minimalist when it comes to my tools, so obviously my experiences and insights are very different from someone working in an IDE. I prefer the command line to a gui any day.
ndl 16y ago
A big theme in programming is to get as much complexity out of one's head and into the computer as possible. In this regard, I consider the IDE an extension of the high level language. Whether I use one depends on what I'm coding in. I'm usually fine with gedit when coding Python. In Java, the IDE helps cut through the verbosity. There is some truth to this article - humans are much worse than machines at simple, regular processes. Manufacturing eventually figured out how to divide up labor along the assembly line and automate as much as possible to make the process regular. Software is comparatively in its infancy. Maybe we will see a similar progression as companies replace the artistry of software with more standardized, repeatable processes. I probably won't be coding then. Kind of reminds me of http://xkcd.com/378/ http://xkcd.com/378/
JaredRichardson 16y ago
I've posted a follow up article. You're a Bad Manager. Embrace It. http://agile.dzone.com/articles/youre-bad-manager-embrace-it http://agile.dzone.com/articles/youre-bad-manager-embrace-it I'd appreciate any help spreading the word. I'm involved with much more of the technical sites than the managerial ones.

75 points by Garbage 16y ago

Great post! Some suggestions that were new to me, too, although you're mixing Java and Ruby in your examples. I agree with everything except the DSL stuff at the end. People have mentioned on HN recently, and I believe it is true, that Cucumber, etc. may be something customers get involved with in the beginning, but then they lose interest in it. Sure there are a number of other things that vary from place to place like politics, conformance to standards, etc. But, customers typically just want to see results (in a reasonable amount of time). If you spend time on good design/UI/UE (read "nice looking and easy to use"), it is fast, it doesn't break, and you've tweaked to their needs, you're set.

JaredRichardson 16y ago
I've spent more time in Ruby and Java than other languages. My background is leaking through. :) Feel free to post any other tools to the comments on the article. Re: DSLs... I don't think the DSL specs always stay in front of the customer (they sometimes do), but they're a valuable tool. Whether it's a developer, a technical customer, or a non technical customer, you've provided a much simpler way to show what the system does. That's a huge win. I also find that developers who spend time in DSLs tend to write much cleaner code. Once you get used that level of abstraction, you use it in other places.

kahawe 16y ago

This simple and completely true statement never ceases to fascinate me: > In short, as an industry, we all stink. We really do stink and we as an industry are nowhere near a state where there are any real standards and best practices in place like e.g. when building a skyscraper or a road. Those are fairly to pretty damn complicated tasks and there is so much knowledge, experience and best practice involved and everyone in the construction industry (should..) knows them and when it is done you can have it checked and certified that it was well built and won't crumble the next day. I don't think anything like this even remotely exists in IT. We have a lot of RFCs describing protocols and what not but nobody can really objectively certify your serious-business software as well-built or can verify whether you applied even the smallest best practices or common sense guidelines because there are so many almost religious wars being fought over completely minor advantages and dis-advantages which simply do not matter on a global scale. And far too many really, really actually bad programmers just get away with their mess or horrible, insane code.

twymer 16y ago
I think the use of some of these strategies mentioned are what should be best practice. Code coverage checkers and code analysis tools, most specifically.
mechanical_fish 16y ago
We need to remember that computers are young. Really, really young. The invention of the first-ever electronic digital computer is still an event within living memory. This can be hard to remember. Especially when you yourself are young, you're used to thinking of things that are even slightly older than you as eternal. (When you reach my age, and you are beginning to have colleagues who literally weren't alive during formative periods of your early career, you get a deeper appreciation for the fact that people -- including yourself -- have these horizons.) For example, I did graduate work on lasers, and I built my work on top of a great deal of earlier work, so I tend to think of lasers as things that have been around for a long time. But the laser isn't very old. It turned fifty this year. Many of my friends are older than the laser. Many of its early pioneers are still wandering around. Look up the early years of engineering. Read certain chapters of the excellent Structures, or Why Things Don't Fall Down, or for a more personal view check out Chapter 20 of Mark Twain's Life on the Mississippi: http://www.classicreader.com/book/2886/21/ http://www.classicreader.com/book/2886/21/ The early history of tall buildings is the history of towers falling down. The early history of modern bridges is the history of bridges collapsing. The early history of steam-powered transportation is the history of boiler explosions, especially in the USA, which had a reputation for quick-and-dirty mechanical hacks as far back as the early 19th century. These situations took decades to change... or longer. Sometimes an order of magnitude longer. And, crazy ideas about the Singularity notwithstanding, technology proceeds at a human pace. Right now, we're still at the point where substantial portions of the world population don't even have access to a computer (although the smart phone promises to change that). Very few people know how to program at any level. And that is the major issue facing programmers today, as it has been since the microcomputer was invented in the 1970s: There is more value in spreading the temporary hacks around more widely and cheaply than there is in inventing more permanent and solid stuff. Until we can meet the insatiable and growing demand for poor implementations of 1970s-era computing technologies, there's really no time or money for anything else. This condition is probably temporary, but when I say "temporary" I may still be talking on the scale of decades.

Tichy 16y ago

I am struggling with that: how to market myself as a consultant, knowing that all code sucks?

twymer 16y ago
Just remind your clients that your code sucks less than your competitors.
- mgkimsal 16y ago
  Indeed, knowing that things suck and being able to document why they suck, and why your approach is somewhat better is a good skill. It's not all smoke and mirrors - it's providing a somewhat objective assessment of the situation. I provide unit tests and documentation for projects - many others don't. Well... showing that to a client and saying "you're getting this which will help you understand what I'm doing, and help future devs understand what I did" is just good sense. If the client values it, they will pick you over someone else. If they don't value it, they will after they choose the cowboy over you . :)
access_denied 16y ago
This is a strategic decision your clients have to make. So basically it comes down to you wanting a) talking to clients about these issues 'consulting' or b) not talking about these issues. What do you want? Which working env is what your business should be to you? If you are ok with talking about these issues to your clients, you should set it up in a way that let's you charge consulting fees for all the talking. Then you can take your time and educate about code quality and what it means for your clients if they buy bad code. The alternative is of course to work only on projects where you are the only coder A-Z. (Maybe I can write a more helpful text, if you make your question a bit more clearer.)
patio11 16y ago
"I made X several million dollars." Why talk about code?
- 16y ago

jasonlotito 16y ago

It reminds me of the saying (probably butchered here) that the more we learn about a topic, the more we realize how little we really know.

twymer 16y ago

The article starts of a little depressing, telling the reader that humans are bad at programming and we have no hope. At least it finishes telling us we just need to use a bunch of cool toys to look smarter.

argv_empty 16y ago

We can't remember all the methods our code needs to call, so we use autocompleting IDEs to remind us. I thought memorizing all of the details of these was only important in school, and even then only at exam time.

olavk 16y ago
I always thought it strange to consider it 'cheating' to rely on a powerful IDE. A programming language is a tool - nobody think it is cheating or a sign of weakness to use the most powerful/productive programming language suitable for a task. An IDE is similarly a tool, which complements the language - just as the code we write is basically a tool.
regularfry 16y ago
Not true. If you have the details in your head, you can manipulate and compare them far faster than if you have to rely on an external tool. That means you can rehearse more ideas, faster, which will lead to a better likelihood of picking the best one.
points 16y ago
Remembering things is VERY important. It means you have an instant grasp of the code base, the APIs available to you. It means you can solve problems much quicker than someone who only has a limited memory, or uses auto-complete all the time.
- kenjackson 16y ago
  Remembering the right things is very important. I know the code base far better now with an IDE than I ever did without one. Because it lets me focus on what is really important in the code. I get to focus on code structure, algorithms, I can quickly drill into the code and back out. I can in a few seconds see all uses or all definitions. The thing that makes IDEs great IMO, is when I'm looking at code that isn't mine. The ability to abstract structure from other peoples code quickly is a godsend.

tomlin 16y ago

I've always believed that I am a pretty terrible programmer. I'm cool with that because I know I am gradually becoming better and better each day. I invoke 3 core principals/ideals: * No matter how good you are, someone is always better than you. Yes. Always. * Surround yourself with people smarter than you, rather than shun them egotistically. Intelligence is contagious. * Admit fault, show humility to others who do the same.

edw519 16y ago

Wait, what? OP claims that we are bad programmers because we use too many tools: We can't remember all the methods our code needs to call, so we use autocompleting IDEs to remind us. and then recommends using tools to become better programmers: These tools flag common mistakes... really common mistakes. I know I'm in the minority because I've had this debate with almost every programmer I know, but I do not use an IDE for exactly this reason. I want the "firmware" that knows how to assemble building blocks of code to be in my brain, not in my computer. To me, writing code is like driving a stick shift, for much of it I don't even think, it's unconscious competence. Can you imagine driving a car with auto-complete, color coding, or drop down menus? To this day, I get pissed off when something doesn't compile the first time, usually because of a typo. There's a time and a place for every tool. An IDE or test suite is like a back brace or crutches; they are indispensable when you really need them, but they only weaken you when you're healthy. I guess I draw the line in a different place from OP (and almost everyone else I know).

RyanMcGreal 16y ago
>OP claims that we are bad programmers because we use too many tools I took from the essay that the tools we use are evidence of our bad programming ability, not the cause of it. Incidentally, I mainly code in gedit, for much the same reasons you cite.
DisposaBoy 16y ago
I dislike IDEs for all their features which for the most part I think just add clutter, since I've ever found a use for most of them like debuggers etc. but I'll admit that they are useful if done right and can bring a productivity boost. When I have to write things like: strstr($str, $delimiter) and explode($delimiter, $str) Netbeans ctrl+p comes in very handy in re-enforcing my choice of arguement order because if I make a mistake that's a very subtle bug waiting to happen. or when I have to wrote things like: g_file_new_for_commandline_arg who wants to type that out when they don't have to? or this over and over: AStudpidlyLongName:: when I can just type `ast` and press ctrl+[space] and get the name in a completion list highlighted every single time. or: m_ui->tooBar->addWidget when I can m_ui.t... and have to automatically figure the correct sequence, this comes in pretty handly when you're working code written by other and they decide to use hard objects as opposed more common pointers.

Maro 16y ago

I'm a good programmer. Embrace it! I used to think I'm a bad programmer, and I was. But ever since I'm doing my startup, I'm concentrating on one project in one language, instead of ten different things in 4 different languages. My co-founder and I found and agreed on a practical subset of the language (C++), and we write great code. I'm still a "bad programmer" in the sense that if I wrote Javascript code, it'd not be great, but now I know that the key to success is to concentrate on one thing for a long time --- and actually it's possible to be a "good programmer" if you do that. Okay, I still don't do enough testing, but in our case (distributed DB) the long-term smart solution is to hire a test engineer..

deleted 16y ago
[deleted]
kls 16y ago
You sir get a gold star, The big reason that projects fail is "technology soup", everyone has to get their pet project or technology into the project. It gets worse the bigger the projects get. When you get to the enterprise where the big project are, you get governance and a bunch of design by committee. Where people who are not writing the code, tell the people that are "here is what you are going to use". It is funny but every time I walk into a project that is "fad" programming I see failure. When I walk in a see a bunch of guys heads down, iterating and releasing the most crucial features first, the project always seem to succeed. Maybe the solution is less magic technology dust not more.
- hammerdr 16y ago
  "heads down, iterating and releasing the most crucial features first" That's the key. The "number" of technologies involved is moot. Every piece of software is build upon thousands of layers of technology. Adding one or more ingredients to the soup doesn't necessarily ruin it. Often the simplest way to solve a problem is to duct-tape two different items from different technology stacks just well enough that it works for you. In that simplest case, you may be duct-taping 2 technologies together with a 3rd.

jister 16y ago

A short bio at the bottom of the article says: "Jared Richardson works at Logos Technologies As a recognized expert in the software industry..." Take note of the word EXPERT. He claims developers are bad programmers yet he is an expert. It's contradicting or maybe the right word in the bio should be WORST? :P

JaredRichardson 16y ago
Nice catch! It's just marketing though. Don't read too much into that...

JaredRichardson 16y ago

Hi all. I'm a long time lurker, but when I saw my article made the front page, I made an account. :) I don't think that using tools makes us "bad"... I think pretending that we're "good" when we really need the tools make it much more difficult for us to past our egos and really look for what we need. There are so many great practices and tools available, but most developers I've encountered because things are "good enough". I was hoping to encourage people to try something new. Something a "good" programmer would never need, but a "bad" programmer would desperately want. In regards to knowing the API versus using an IDE... spend some time with a Ruby developer. Someone who's not used to having great IDE support. They've been forced to learn the language. The difference in their productivity level is amazing. Contrast them with a developer who only learned Java or dot Net and was using Eclipse or Visual Studio from day one. Those developers tend to not learn the underlying APIs and I think it hurts their ability to know what functionality and libraries are available to them. Anyway, it's very cool seeing an article I wrote on HN!

TamDenholm 16y ago

Personally i dont use an IDE, i use gedit because it does what i want, colour coding, auto indentation and a file browser pane that supports (s)ftp (but i suppose thats actually the OS), thats all i'll ever want or need. If you want to use an IDE, then by all means go ahead, but if your trying to hire me, dont make me use it, and dont make me use an OS i dont like either. Everyone's different and they've got their own way of working, just let them do it their way and they'll be more productive, they'll achieve what you're after.

SanjayUttam 16y ago

While this doesn't necessarily negate the "we can't remember syntax" argument...I remember back before mobile phones were rampant, I was really great at remembering phone numbers. People besides by parents were regularly surprised at how I'd remember numbers I'd seen or read just once. Then I got a mobile phone. I think I probably have less than 5 numbers memorized (those of my immediate family). In essence, using an IDE encourages us not to memorize syntax.

weego 16y ago

Does anyone still believe there are really any ground breaking insights to be made in these kind of self-loathing rhetoric articles? Shouldn't there be more "You know what, sometimes just having something work is pretty much awesome" articles instead of everything fooling themselves that every programmer in the world needs to be a mini-genuis?

known 16y ago

You're a good programmer if you reuse code.

j_baker 16y ago

Am I the only one who feels the whole egoless programming thing has gone too far? Yeah, ego is a bad thing. But self-esteem and confidence aren't. I'm not afraid to say that I feel I'm good at what I do. That doesn't mean I'm never wrong or that I don't make mistakes. It just means I'm proud of my abilities.

reynolds 16y ago

I can't imagine using autocomplete or even an IDE. I remember when I first started I was writing C++ on Windows in Visual C++. My learning only accelerated once I moved off Windows and stopped using autocomplete. Once I started working on Linux and in vim, I didn't even consider looking back. I like to think I'm a minimalist when it comes to my tools, so obviously my experiences and insights are very different from someone working in an IDE. I prefer the command line to a gui any day.

ndl 16y ago

A big theme in programming is to get as much complexity out of one's head and into the computer as possible. In this regard, I consider the IDE an extension of the high level language. Whether I use one depends on what I'm coding in. I'm usually fine with gedit when coding Python. In Java, the IDE helps cut through the verbosity. There is some truth to this article - humans are much worse than machines at simple, regular processes. Manufacturing eventually figured out how to divide up labor along the assembly line and automate as much as possible to make the process regular. Software is comparatively in its infancy. Maybe we will see a similar progression as companies replace the artistry of software with more standardized, repeatable processes. I probably won't be coding then. Kind of reminds me of http://xkcd.com/378/ http://xkcd.com/378/

JaredRichardson 16y ago

I've posted a follow up article. You're a Bad Manager. Embrace It. http://agile.dzone.com/articles/youre-bad-manager-embrace-it http://agile.dzone.com/articles/youre-bad-manager-embrace-it I'd appreciate any help spreading the word. I'm involved with much more of the technical sites than the managerial ones.