Software Development

10 signs that you aren't cut out to be a developer


Programmers make big bucks. Software developers dress casual every day of the week. Anyone can teach themselves to be a programmer. These are just a few of the reasons why people say they want to become a developer. Unfortunately, the job market is littered with people who may have had the raw intelligence or maybe even the knowledge, but not the right attitude or personality to become a good programmer. Here are a few things to consider when deciding whether you should become a software developer.

Note: This information is also available as a PDF download.

#1: You'd rather be trained than self-teach

In most development shops, there is rarely any training, even if the company has a training program in place for other employees. At best, the company might reimburse you for a book you buy. Programmers are expected to arrive on their first day with all (or at least most ) of the skills they need. Even worse, the assumption is that programmers are really smart people who are good at problem solving. That assumption leads upper management to believe that good programmers do not need training. Finally, training for developers is extremely expensive. The result? When you change positions, you will need to figure out what is going on yourself, and you will probably need to teach yourself.

#2: You like regular working hours

Software development projects are notorious for being late. Even the projects that are delivered on time always seem to run behind schedule at some point. If you don't like (or can't handle) irregular or fluctuating demands on your time by your employer, development is not for you. When crunch time comes, your employer is more concerned with getting the product in the hands of a million-dollar client than with your child's soccer game or the new TV program you wanted to watch.

#3: You prefer regular raises to job-hopping

The world of development is one of continual erosion of skill value. Unless you are working at a shop that deals with slow-to-change technologies, chances are, your skill set is less valuable every day. The state of the art is changing rapidly, and the skills that are hot today will be ho-hum tomorrow. As a result, it is difficult to sit at the same desk doing the same work every day and expect a raise that exceeds a cost of living increase. You need to keep your skills up to date just to maintain your current value. In addition, if you want to boost your paycheck, you need to expand your skill set significantly and either earn an internal promotion or go to another company.

#4: You do not get along well with others

It's one thing to be an introverted person or to prefer to work by yourself. It's another thing to be unable to get along with others, and it can sink you as a developer. Not only that, your manager may well be a nontechnical person (or a technical person who has not worked hands-on in some time), so you need to be able to express yourself to nontechnical people.

#5: You are easily frustrated

Software development is often quite frustrating. Documentation is outdated or wrong, the previous programmer wrote unreadable code, the boss has rules to follow that make no sense... the list is endless. At the end of the day, no one wants to be working next to someone who is always cursing under his or her breath or screaming at the monitor. If you are the kind of person who goes insane spending eight hours to do what appears to be 10 minutes' worth of work, this is not a career for you.

#6: You are close-minded to others' ideas

In programming, there are often problems that have only more than one "right" answer.  [Update: Corrected by author] If you do not handle criticism well, or do not care to hear the suggestions of others, you might miss something important. For example, a few weeks ago, one of our junior-level people made a suggestion to me. After considering it for a bit, I decided to try it. It turned out that he was right and I was wrong, and his suggestion brought the time to execute a piece of code from multiple days to a few hours. Ignoring this person due to the difference in our experience levels would have been foolish.

#7: You are not a "details person"

Programming is all about the details. If you get lost in a movie more complex than Conan the Barbarian or have a hard time filling out a rebate voucher, you probably won't do very well in the development world. Sometimes, something as simple as a missing period can mean the difference between random failure and perfect success. If you are the type of person who might not figure out where the missing period is, your career will be limited in range, at best.

#8: You do not take personal pride in your work

Sure, it's possible to program by the book and do a passable job. The problem is, the book keeps getting rewritten. Software development is not a factory job where you tighten the same bolt all day long, where a touch too much or too little torque makes no difference. It requires independent thought, which in turn requires the people doing the work to take pride in it. Furthermore, it's easy to do something the wrong way and have it work just well enough to end up in production. That "little error" you turn a blind eye to since it doesn't seem to cause any problems will cause problems. Programmers who do not treat each project as something to be proud of turn out poor quality work, which in turn makes their careers short-lived.

#9: You prefer to shoot first and ask questions later

Software developers, at least the good ones, spend a lot more time planning what they're going to type than actually typing. Usually, when coders just open up their code editor and start banging away at the keyboard, most of what they write gets ripped out later. Programmers who ponder, think, consider, and plan write better code in less time with fewer problems. There's a reason so many programmers barely know how to type properly: The hard part of the job is knowing what to type. People who do not invest the time up front in their zeal to get started with the "real work" are actually skimping on the "real work." If you are a doer and not a thinker, software development is probably not a good career choice for you.

#10: You do not like the geek type of person

For a bunch of reasons (some legitimate), a lot of people just do not enjoy being around the engineer or techie personality. If you have a hard time with the Dilbert or Weird Al personality type, do not even consider going into programming. Are all developers like that? Of course not. But they comprise a large enough portion of the workforce that you would be miserable in the industry.

About

Justin James is the Lead Architect for Conigent.

125 comments
OptionR
OptionR

Why does every programmer and or developer, even this site say you have to self teach?????? WTF!!!!!!! I can try and teach myself PHP like I have been for the past 3 years still dont get a THING about it!!!! NOT ONE!!!!! Plus why even go to school or get educated at all??? Just teach your self and dont do what the internet was intended for like SHARE INFORMATION!!!!

sjzizou
sjzizou

iv done my engineering in computer science wid a pretty good knowledge bout most of the subjects .........but iv got no interest in coding but iv good communication skills.........is der a job profile which is apt in a situation like mine.........

iriley.qa
iriley.qa

Are there developers out there who didn't major in Computer Science, Math or related degrees? Sure. But the line of demarcation becomes painfully obvious the more complex the software need gets ... and it is sure obvious where best practices are concerned. Straining the limits of computer science is still a top-10 software risk. The right academic background helps to eliminate that.

chris.smith
chris.smith

I have done the whole 2 month 10 to 12 hour days thing and ultimately it's not worth it. I feel like the more that developers make this the norm, the more it becomes standard practice in the industry. Then of course if you want to be the guy who goes home at 5 or 6, then your considered a slacker. Clearly I expect to work late hours sometimes (deployments, server crashes, smaller client emergencies) but I think all developers in the industry should not let themselves become 60+ hour workers (ie your lack of a personal life and work compensating for that is bad for the industry in general... If you make it a norm). I especially feel like young developers (like myself) are expected to do these long hours just because we have the energy to do so. But let's remember that programming is an art to some extent and we all love writing good code but when you kick the bucket, it's ultimately going to be your friends/family/lovers that matter, not the business layer you spent 3 or 4 months of your life slaving away on.

mikifinaz1
mikifinaz1

So far most of your ideas are well... not common. Let's take one of them, I love to watch an employee waste tons of time chasing their tail trying to learn something on their own and point this out to the employer and the fact that I learned to do it in an afternoon going to a class. Also, the type of person that is so dogged usually doen't work well with others in most ways and will keep beating a dead horse as you allude to again and again. Another trait that most employers don't like no to mention co-workers. These endearing traits probably are the reason programming is not on most people's to do list, even if they have the ability to do it.

Noonelse
Noonelse

Doesn't matter I can't get a job doing it anyway.

dbrown6
dbrown6

Well written and accurate. Thanks for keeping it real.

john3347
john3347

And #11: You just got hired by Microsoft as a development team leader. (You must fit all 10 above to qualify for #11.)

retro77
retro77

You forgot one: If you fail your college programming class [C++] two semesters in a row.

Tell It Like I See It
Tell It Like I See It

Like, dude, you need to know the right paradigm for generating verbal signals when interfacing with us in audio mode. You expect us to grok your thoughts??? I have an idea -- CAT-5 brain implants so we can FTP over TCP/IP our thoughts directly. Of course that means we need to clarify who is the domain controller and whether the other is a member server or a dumb terminal. Perhaps we can do better with ASCII files run through the 'more' pipe. Maybe if we used HTML e-mail via 802.11g. Then again, what about an RPC via SOAP over TELNET? Okay, I've officially scared myself with the above, which is fitting since today is Halloween. Now to get a bit more serious. The best developers (as opposed to code-grinders) need to be able to communicate with normal people. This means either avoiding the technospeak altogether or else teaching them what a given term means when you use it. This is essential for requirements gathering and "selling" your proposed solution to management or clients. These same "best developers" can turn around and, if necessary (but hopefully it isn't), spout out the technobabble that the code-grinders need to hear in order to do their coding. Okay, I can't resist one more technospeak item :) Now it's time to CTRL-Z

rgsemail
rgsemail

I'd say about 1 in 1000 software people have all those great qualities. That's probably why most systems everywhere are in such horrible shape. So, don't let a failing grade on this checklist discourage you. Just jump right in and join the crowd. That's what most developers do because they have no idea what else they'd do for a living.

alaniane
alaniane

One I would add is knowing that programming as a hobby is different from programming as a professional. When you program as a hobby, you can pick and choose the interesting stuff; however, when you program as a professional, you will have to do a lot of mundane tasks over and over again. Many of the projects that you will be given to do will involve similiar code and you will use similar algorithms to accomplish it. Also, expect to have to tweak what the drag-n-drop IDEs generate. In most cases, I have found that you are better off coding it yourself than allowing the code-generators to generate it for you. Unless, it is extremely simple code or the project does deviate much from the norm, the code generators are liable to screw up the code.

MadestroITSolutions
MadestroITSolutions

Man, I feel like forwarding this to some people I know, lol. I totally agree. Very kewl!

mhpries
mhpries

This is a fun and even useful article, although somewhat mean-spirited, for team leads and project managers who have to deal with identifying misfits and helping them move along but let's face it, people who actually have these traits are not going to read this in the tone that it is written and admit they see themselves. Nobody is ever swayed by an argument that requires they view themselves in a negative light.

mikes
mikes

Once upon a time, when computers were used for nothing more than raw number crunching, it was okay to approach software with little more than an understanding of the hardware. Now that the two are so far removed for most projects, with the OS being of far greater importance than the hardware, "elegance" tends to define success. That means giving the client what they need rather than what they ask for. It means understanding the business requirements as well as the algorithms. Most certifications only focus on the technical aspect, which is easily outsourced to the lowest bidder. Quality development cannot be outsourced, because it's based on the relationship between the business and the tools that drive it. Developers that don't get that really need to choose a different career path before the next bust forces them out.

ByteBin-20472379147970077837000261110898
ByteBin-20472379147970077837000261110898

Yup, that's life as a developer - even web developers since we often have to deal with everything from 'proper' xhtml/css to javascript, .net, databases, CGI server scripts, you name it. As for when I get to sleep - when I'm able to stop coding for a few hours to GET sleep! LOL! Even if you work from home it does not gaurantee you a 'life' as such. You still can get QUITE busy. Adding to the list should be that you should be well organized. Keeping your notes where you can find them (not spread all over the hard drive and desktop, but in proper folders with the projects), keeping your TIME organized, allowing for those late-night coding sessions and realizing you may have to pay your bills the NEXT day after you planned. And if you don't like to do research, you don't stand a chance. A lot of googling helps even the best programmers. Web developers look at what everyone else is doing for a couple reasons: What works and what doesn't and also to be sure their site is very different and unique from what is out there. Ever have a boss that also can code? I do. Yup we get along good and work well as a team. Not everyone is as fortunate. If you are coding along side of your boss, always try your boss' idea FIRST and THEN suggest your idea IF it doesn't work. And be prepared to be able to intelligently give advice on code, design, etc. when asked 'what do you think?'. Be prepared to be told 'that's not the way we're going' a few times. Don't feel bad. We aren't all mind readers so it may take a few tries to get on 'the same page' so to speak. Eventually you will understand what is going to be done if you keep your ears open, and ask questions. Don't be afraid to say you need more information on a detail. That's how you'll find out what their needs are. I love my job as a web developer/programmer. I enjoy the projects. The biggest reward for me is seeing the project done and realizing I (or I and my boss) created something really cool. We do take pride in our work. And if you do that, then you will have reason to feel you've been rewarded just by seeing the project working. :) It's not an easy job or for everyone. But I knew I always wanted to be a programmer since my teen years when I started programming on TRS-80s and Apples. And I spent hours and hours learning and altering code in books, etc. It's all I wanted to do. And 99% of what I learned I learned myself. I've had some schooling, yes, but most of what I learned was through years of writing code. The schooling I get is to just keep up to date and my skill current.

SnoopDougEDoug
SnoopDougEDoug

What about the popular misconceptions devs have to face? Top ten signs that you are not cut out to be a developer according to Hollywood: 10. You do not wear a trenchcoat and fedora 9. Your apartment is not strewn with empty pizza boxes and coke cans 8. Your girlfriend isn't a goth 7. You did not graduate from college at 12 6. You don't wear glasses 5. You don't drive a car crammed with electronics, especially a radar jamming device 4. You speak in complete, grammatically-correct, sentences 3. You comb/brush your hair 2. You are female 1. AND #1 WITH A BULLET: You cannot sit down at a keyboard, on any computer on earth, which you have never seen before, and immediately hack into any system on earth, be it the CIA, NSS, Russian Mafia, and get/set any information.

gmiller1018
gmiller1018

11. You are not into creative problem solving. You dislike puzzles and do not like problems that are not obvious.

DRAGON53532000
DRAGON53532000

One other sign you are not cut to be a programer is if you are amazed when you wake up that you grew a dorsal fin. LOL this was a joke.

Tony Hopkinson
Tony Hopkinson

Surely there must have been something, you just spent years of your life getting the degree. There are lots of jobs in IT that aren't programming. Analyst Usability Security Tech( hard ware, network, admin) Management QA Technical Author

NEViper
NEViper

Sorry Chris Smith but software engineering has become blue collar including endless, profit saving (usually free) OT. With the industry being intentionally flooded with imported labor, it's not likely to get any better.

apotheon
apotheon

Who is jkameleon? Is that the guy who ranted a while back about how people who are self-taught don't deserve to have jobs?

Tony Hopkinson
Tony Hopkinson

If you pass it with flying colours impressing you examiners with your understanding of obfuscation, elegance, complexity, mutiple side effects etc.

Justin James
Justin James

So sadly true. I wish the industry had "weed out jobs" like college has "weed out courses". We used to have that, when Help Desk or "Operator" was how you got into IT, but now, anyone who could fumble their way through a 4 year Java vo-tech school (I mean, typical 4 year CS degree) lands in a $45k/year job in a few months. J.Ja

MadestroITSolutions
MadestroITSolutions

I have to say I am torn when it comes to IDEs/code generation. On one hand, we get paid to do a good job, and IDES/code generation tools can definitely save some time (which translates to money). On the other hand, developers tend to "disconnect" from their applications and what is going on behind the scenes. Developing not only involves making something that works, but also being able to fix any problems and/or improve performance, and that can only be done by knowing the inner workings of the underlying technology. I know many people out there who are using tools like VS 2005 with ASP.NET or what have you to design sites and don't have the slightest idea of how the compiler works, or why their application is running so slow. All they know is drag and drop on the design surface and boom, the page is connected to the database. I mean honestly, just think about it, how many of us have grown so accostumed to intellisense that if you are to code something manually, you probably don't remember half the methods of a .NET GAC assembly class, lol.... I personally am an old school guy and even though I do take advantage of some of the features of the IDE, I try to code as much as I can by hand. This way I have full awareness and control over my applications at the same time that I make sure my knowledge is up to date without having to press F1 every 10 minutes to try to remember what a method does. As far as hobby vs professional, hobby is definitely more fun. You can learn more advanced stuff on your own and use it for future jobs. The only problem I personally face with hobby programming is that I never finish what I start!!!, lol... I always find something else that sparks my interest and leave all sorts of projects behind, lol... I sux :)

ByteBin-20472379147970077837000261110898
ByteBin-20472379147970077837000261110898

You're right. I remember back when I was just coding for fun I would do stuff I needed a program for to do something else, or just play around with some interesting stuff and add ideas of my own. Now, it's whatever the boss needs. And while most of it is interesting, there's also an element of you really have to get this finished. There's been some projects put on the back burner but none abandoned. When you're coding just for a hobby, you're free to forget about a project altogether if you don't feel like doing it anymore. But I luckily I haven't come across a work project I didn't want to do. I guess I'm one of the more fortunate ones. As for IDEs, I discovered that quickly when I started using Visual Studio 2005 and programming database-driven web sites. Often you'd have to tweak the code for the database stuff.

Tell It Like I See It
Tell It Like I See It

With regards to commercial code generators, you are correct -- most suck at anything other than the most basic code. That said, however, when you are doing the same mundane tasks over and over again, why not write your own code generator? Then it will generate the code you want it to generate. This can be as simple as an Excel spreadsheet that you use to "generate" repetitive lines of code with only a few variations. Or, it can be something as complex as something that connects to a database, reads the field information about a table and builds an entire screen (or web page) from that information. After all, if you build the generator, you are in total control of the code it generates.

Justin James
Justin James

I know exactly what you mean. My "hobby"programming has always been more interesting... and more advanced than my professional programming. In fact, I have found that it is the code-level skills learned in "hobby" programming that impress at the job interview, not the "how to hook yet-another-database-to-HTML" which comprises most "professional" computing! J.Ja

Tony Hopkinson
Tony Hopkinson

A tidy desk is a sign that you don't have enough to do. I've had several bosses who thought they could code , but I squared them up. If anyone's idea seems better than mine I'll try it. Trying it because it's somebody's, well only if it's horrible and I want to make a public example of them.

Justin James
Justin James

I was actually going to pitch this exact same article to the editors, and you took about 7 of the ones I was going to use! Argh again! The ones I *wasn't* doing was #8, #5, and #4. Indeed, instead of #8, mine was going to be, "you have currently have a girlfriend or wife." At best, in the movies, geeks have ex-wives who got tired of playing second fiddle to the compiler... Oh, and #1 is slightly incorrect. The system is not limited to Earth. Let's not forget "Independence Day" in which the hacker kludges together a system destroying cirus on a Mac and manages to upload it to the alien computer system. It's a good thing that Cocoa is a universal language ("bon weep grana weep mini-bon!") and that they read their email that said, "click here for H3rb@l Remedi"... J.Ja

Former Big Iron Guy
Former Big Iron Guy

In no apparent order: You also cannot hack into systems "off" earth (ID-4), Star Trek various series (especially The Borg). You cannot penetrate any system over your cell phone. You cannot hack any criminal's internet feed set up to taunt you. (CSI: any, NCIS, Criminal Minds, Numb3rs, hmmm do we notice a trend as to network and production companies?) You can't suffer a virus or other malware disaster without smoke, flashes and booms. See above...

alaniane
alaniane

I have plenty of hobby programming projects that are still waiting to be finished. Some of them are a couple decades old back when I was playing around with Assembly and C.

Justin James
Justin James

I have completely stopped using Visual Studio's database tools, and the .Net databound controls. They have done nothing but cause me misery. Unless you are hashing out something dumb, like the stereotypical CD collection app or recipe app, they just get you "stuck", and when you need something custom, it sticks out like a sore thumb. J.Ja

alaniane
alaniane

that I was talking about using out-of-the-box code generators. I agree that writing your own code generator is useful if you are doing a lot of same type of code. Also, for UI development using the IDE's code generator for creating the controls can be useful. However, relying on the code generator to hookup the data links for those controls can be fraught with problems.

MadestroITSolutions
MadestroITSolutions

I can relate to the "do what your boss" says thing simply because at the end of the day, he makes the call, not us. Our idea/implementation may be better but ultimately we must follow the lead. Our job is to give our professional assessment so he can make an informed decision. Whether he makes the right one or not (from our perspective) unfortunately is beyond our control. It's called politics. Squaring bosses up will only get you further away from any promotions or oppotunity for advancement. It appears to me that you are being very subjective when you try things because you "think" they are better than yours. I can relate because I know us developers take great pride on what we do, but in order to be as productive as possible we must learn to work as a team, and that means to have our minds open to feedback or other ideas. In my experience there are two kinds of people: 1) People who listen, process the information and make a decision about it 2) People who "listen", process the information looking for possible flaws in what you are saying in order to discredit your ideas and prove theirs are "better". I personaly like number one.

ByteBin-20472379147970077837000261110898
ByteBin-20472379147970077837000261110898

I mean in terms of where you put your notes in your computer, and how you comment your code. If you can't find what you need (the info you need), then you'll get lost quickly. Also I learned it's best to sit down and plan out a larger project if possible so at least you have a To Do list handy so you don't get lost. Having some good organization skills are a good idea. As for my desk or my home office in general - you don't want to know. LOL!

Justin James
Justin James

L & O taught me that people (I mean, criminals) use the same handle across all chat rooms, message boards, etc., and that they all advertise their IP address in the same chat rooms, allowing their whereabouts to be easily traced. J.Ja

Tony Hopkinson
Tony Hopkinson

One of the most regular DB application questions on this site is with my databound control, how do I do this. Sometimes you can, but it usually turns into an unmaintainable kludge. You lose control, and you lose granularity, which explains how bloated and inefficient they are.

john_ludlow
john_ludlow

I've been accused before (perhaps fairly) of rejecting ideas of others out of hand and it can seem like I only go with my own ideas. But on the other hand, I'm a developer in a fairly specific area: installations, primarily MSI. Now, installations (MSI in particular) can seem like a dark art some times. Things that can seem simple (adding a new dialog into the sequence, for example, or dynamically building the file structure by scanning a folder) can actually involve weeks of work, or might just not work at all. So quite often I say no to an idea for very good reasons which might not be obvious to someone from a different field. I also have a habit of spotting issues and bringing them up early. This also annoys people sometimes. But, to be perfectly honest, this is what I get paid for. If I see an issue and don't mention it and it ends up being a real problem for us, who's the idiot? Me. So there's the two types, though it's not always easy to distinguish between the two.

MadestroITSolutions
MadestroITSolutions

Unfortunately nowadays a lot of good stuff gets lost in corporate bureocracy... That's why I gave up my job in N.Y. City for a comparable pay (considering the cost of living), more decision making involved one in N.J.

Tony Hopkinson
Tony Hopkinson

People who listen and hear and talk and confirm I'll accept a better idea from anybody, it won't get marked as a better idea because you are 'somebody' though. As for promotion, I've aklways been a failure on that front. You want me to put my nose where ? It'd had better be a bloody good pay rise, is all I can say.

jensgeyer
jensgeyer

Tony, a (good) comment describes a piece of code on a higher level of abstraction. A good comment gives the reader a good idea what the writer of the code originally INTENDED to do. For example, think of the not so uncommon scenario where one has isolated a bunch of lines that do something irritating. More often than not, the question arises what is really wrong here: Is it the code? Or is it your understandig of the code? Should this routine by design do it that way and return that result? Or do you overlook something important, and the code and the result is indeed completely correct? More worse: You got a bunch of legacy code on your desk in order to maintain it. Code poorly documented, poorly structured and without a single line of comment. The code deals with some technical, mathematical or engineering stuff of a given complexity, not easy to understand even without code. I can almost hear you yelling about the moron that wrote that sh***y code, completely un-understandable, un-maintainable and it should be canned and rewritten from scratch. Ok, but ... you really want to rewrite 350.000 lines of actually working and productively used code? And yes, such code exists out there in the wild, and not everybody has the opportunity to build new code on green grass. Where I fully agree is the fact, that misleading comments are more worse tahn no comments at all. But concluding that comments are therefore evil in general and should be banned from the code sounds to me like throwing out the baby with the bath water. So please, Developers, take care of your comments! They will be a great help, if you use them right. JensG

MadestroITSolutions
MadestroITSolutions

No matter how good you are at writing "clear code", comments can always save the reader time and effort. Following the code in a 1,500 line of code application may not be tough, but a fully fledge 30K LOC app can have you scratching your head for a while. Stubbing can serve as a general description of a class or method's purpose, but I doubt you will have enough information in there to describe the implementation, which is what comments are for. Comments can give you details about how a particular sub of function is implemented, allowing you to skip the reverse engineering process. Comment lines are (obviously) not included in your assemblies, so it's not like it has a performance or size impact or anything like that. It can only help make your life easier. I don't know about you, but I have so many applications that every time I go back to them, I have to review what I have done in the past in order to work on them, and comments are definitely a big plus. My desk is a mess by the way, lol....

Tony Hopkinson
Tony Hopkinson

instead of an external documentation I have no problem with, I do that for my own benefit. At the point it's written and before the to do is done, it qualifies as a meaningful comment. We use an external tool so we can cost up parts, show design and indicate how far along it is, to management, so short of aide memoires it's not part of the process. If that isn't required you might as well do it in the source, with the proviso that how that is managed into files is well understood or comprehensible by the team. Seeing comment as a failure though means when the To Do is done, it should either be removed (my preference), or religiously marked as complete. If you want to make the next developer to work on it, pucker up in the nether regions, do this. Some Routine // This seems to cause an AV in certain // scenarios. We will have to look at it. Now when you see this in released code while investigating a bug in the wild, you need really thin toilet paper. This is my biggest poblems with comments as a documentation method. How do you distinguish the relevant ones ? Irrelevant / misleading comments are worse than none. Commenting properly requires a lot of resource that would be better spent trying to obviate the need for them.

ByteBin-20472379147970077837000261110898
ByteBin-20472379147970077837000261110898

I have posted an article about why I use comments a lot. They especially are useful when you want to remember where you left off, or ideas you hope to implement. http://bytebin.net/articles/2007-0127.html Also I would comment code if I'm working on something with someone else so I can let them know right there (instead of them having to read email first) what I plan for the future. Even the best written code can also be rather confusing if you have tons of lines to get through. So separating things in block and commenting them are often useful. Especially when you have to scroll through it all. Helps you (especially in color syntax highlighting IDEs) find parts of your program quicker. Everyone has their way of working on things though. YMMV.

Tony Hopkinson
Tony Hopkinson

I like. Faulure to write readable code might be situational such as an API, a quick fix with a vague hope of refactoring later. Time pressures... What I loathe is explaining the obvious in 'english' or just as bad being too lazy to make it unnecessary. int i; // the number of invoices for instance. or int numberofinvoices; // the number of invoices. just as a bad a description of the code in pseudo code. I can live with failing to write readable code , but I can't accept not trying. Far too many do and then call it a virtue because their garbage is littered by comments. xdoc I can see uses for, especially when there's no external documentation process. I really like using region as well and standard layouts for code. Fields, Properties, Constructors, interface implementations ... are great aids in comprehension, which is a massive part of mainteenance and enhancement. Simple, cheap and immediately adding value, built in quality, as opposed to one size fits all externally imposed drivel, which usually get's lost racing to meet a production target. My biggest argument with accademia is the emphasis on good coding habits is summed up by litter your code with comments, a substitute for quality.

john_ludlow
john_ludlow

I think it depends on what the code is doing. There's a few situations where commenting is A Good Thing(tm). XML comments in .NET (and the equivalent in Java/C++/whatever) is good if someone might need to reuse your code at some point. It saves them having to actually figure out how your class works, since these comments allow a modern IDE to simply tell them. It can also be used to generate CHM or web-based documentation in the MSDN stylee. There's also going to be occasions where it's simply not obvious what's going on, through no fault of the actual coder. Maybe they're forced into using an API that isn't very well put together. Maybe they ended up using a little trial and error to solve some weird bug. And so on. And then it also depends on the actual language. I've been developing an installation using WiX, and I've been putting comments all over the place. That's because I got all the file lists together, but it wasn't easy to see which components are installed under which features, because that's defined elsewhere. So I put the comments in to help make it clearer. Each component has a comment explaining where it ends up and what feature it belongs to. I know you're not saying that comments = bad code, but I just felt the need to call out that exception there.

Tony Hopkinson
Tony Hopkinson

to be a failure to write readable code, you won't see many, but they are worth reading. I do distinguish between comments and documentation e.g. purpose statements though, particularly for domain specific jargon ffor instance. My nod to orgainising is stubbing out methods and class / interface carcasses and To Do Lists in our project management system. The key to me is meaningful minimums that add to the processs of development, not take it's place or only exist in my head which is less tidy than my desk. :D

Locrian_Lyric
Locrian_Lyric

TV criminals never think to spoof, have troll nicks or sock puppets, and never ever ever hack anyone else's account. No wonder they are always so easily caught