The 7-Year Developer Crossroad(discuss.joelonsoftware.com)
discuss.joelonsoftware.com
The 7-Year Developer Crossroad
http://discuss.joelonsoftware.com/default.asp?joel.3.761345
6 comments
There are a couple of implicit fallacies in the follow up comments that bug me.
1. Someone asked if the badly written code was really causing any problems, and then everyone thereafter seems to just take as an assumption that badly written code does not create any real problems. Well, badly written code often does cause performance problems and disguise bugs. I have inherited code bases where things were taking ridiculously long because the code was a convoluted and almost incomprehensible mess. Making it simpler and more comprehensible was a necessary prerequisite to make it operate at a reasonable speed.
2. There seems to be an assumption that you can write code rapidly or comprehensible code, but not both. In my experience, programmers who write incomprehensible code are not more productive than the programmers who write comprehensible code, often the opposite. There is no polite way to say this, but incomprehensible code is more often the result of less knowledge or intelligence than it is the result of a desire to get a lot done. Furthermore, stopping to think before coding can often lead to much shorter development times than just diving in and typing the first thing that pops into your head.
When I have been in the role of technical person with non-technical management, my implicit approach is "evaluate me on what I produce and how quickly I produce it, but stay out of the code." If I am being hired because of my knowledge of how to make computers do what you want, evaluate me on that, and let me figure out the best route to get there.
1. Someone asked if the badly written code was really causing any problems, and then everyone thereafter seems to just take as an assumption that badly written code does not create any real problems. Well, badly written code often does cause performance problems and disguise bugs. I have inherited code bases where things were taking ridiculously long because the code was a convoluted and almost incomprehensible mess. Making it simpler and more comprehensible was a necessary prerequisite to make it operate at a reasonable speed.
2. There seems to be an assumption that you can write code rapidly or comprehensible code, but not both. In my experience, programmers who write incomprehensible code are not more productive than the programmers who write comprehensible code, often the opposite. There is no polite way to say this, but incomprehensible code is more often the result of less knowledge or intelligence than it is the result of a desire to get a lot done. Furthermore, stopping to think before coding can often lead to much shorter development times than just diving in and typing the first thing that pops into your head.
When I have been in the role of technical person with non-technical management, my implicit approach is "evaluate me on what I produce and how quickly I produce it, but stay out of the code." If I am being hired because of my knowledge of how to make computers do what you want, evaluate me on that, and let me figure out the best route to get there.
It's weird hearing people say not to focus on cleaning modules because they're a waste of precious resources. Down the road, the code is all you've got - you must keep it in as good a shape as you can. The more "technical debt" you acquire, the harder it's going to be 2 or 5 years from now to stay competitive. Hacks might sell version 1, they might even sell version 2 and 3, but come versions 4, 5 etc. it's going to be increasingly hard to add features and fix bugs without breaking the whole thing. I've been on two such projects in my short career and it wasn't fun. It's one thing to work with a complex codebase, and it's completely another to work with a badly mentained complex codebase - it sucks the pleasure of programming out of you.
As I've said - code is all you've got in the end, and if it's good, the shipped product will reflect that.
As I've said - code is all you've got in the end, and if it's good, the shipped product will reflect that.
to me, this person's rant comes across as whining more than anything else. it reminds me of the old quote about theory being the same as practice, but only in theory. being in a similar situation, i'd counsel her to recognize that being a professional developer involves much more than writing code. sure, we were taught to espouse the pursuit of code nirvana when first learning to program, but when tossed into the world of industry, that pursuit is quickly replaced by pragmatism and understanding that not doing something right doesn't necessarily mean you're doing it wrong... i'd keep going, but at this point i'd just be rehashing edw519's points... http://news.ycombinator.com/item?id=669163
understanding that not doing something right doesn't necessarily mean you're doing it wrong
But it might; that is the other half of pragmatism. Being pragmatic is not just a softer way of saying self-defeatist.
And don't be so dismissive of theory. To quote W. Edwards Deming: "Experience by itself teaches nothing...Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence without theory there is no learning." Just doing what you discover is done in practice provides absolutely no room for improvement outside of rare flashes of intuitive brilliance. Theory is not just an abstract description of what has been observed concretely so far; by far the greater value lies in the ability for theory to predict what has a likelihood of being observed in the future. Having a theoretical basis to work off of will give those experiences context, and will give you the ability to do a much deeper analysis. And analysis, if the comments Sara received are any indicator for, is something we need to be doing a lot more of.
But it might; that is the other half of pragmatism. Being pragmatic is not just a softer way of saying self-defeatist.
And don't be so dismissive of theory. To quote W. Edwards Deming: "Experience by itself teaches nothing...Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence without theory there is no learning." Just doing what you discover is done in practice provides absolutely no room for improvement outside of rare flashes of intuitive brilliance. Theory is not just an abstract description of what has been observed concretely so far; by far the greater value lies in the ability for theory to predict what has a likelihood of being observed in the future. Having a theoretical basis to work off of will give those experiences context, and will give you the ability to do a much deeper analysis. And analysis, if the comments Sara received are any indicator for, is something we need to be doing a lot more of.
My strong point is that I communicate well with people, and I'm not afraid to take an issue up with someone -- be it colleague, manager, or client. I will take initiatives to get things done. And even if I'm going to do it just once, I'll get it done _RIGHT_. I am decent developer, but some people take issue with me because I'm not as fast as the hack... I mean other coders. ;) I've heard people remark that I could be a Project Manager, but too bad I feel they don't do anything but useless admin work. (And get in the Developers' way!)
this paragraph smacks of "I do it right, everyone else does it wrong." my point was that the "right" way, as learned "in theory", is not necessarily so in practice (and in fact, often isn't when the theoretical right way involves spending client money that will add no value that is immediately noticeable to the client). i wasn't dismissing theory as useless--if you read my comment as tilting to that extreme, i probably wasn't clear enough. theory has its place, but if a dev goes through her career expecting her clients/bosses to agree that spending time refactoring so-so code (that works!) is worth $XXX/hr, it's no surprise she's getting frustrated. in my mind, her role as a developer is to apply sound theory as much as possible within the constraints of her job. when other people are signing her paycheck, she either does it their way or finds a new job (or applies to YC)--but complaining about it won't help her situation.
this paragraph smacks of "I do it right, everyone else does it wrong." my point was that the "right" way, as learned "in theory", is not necessarily so in practice (and in fact, often isn't when the theoretical right way involves spending client money that will add no value that is immediately noticeable to the client). i wasn't dismissing theory as useless--if you read my comment as tilting to that extreme, i probably wasn't clear enough. theory has its place, but if a dev goes through her career expecting her clients/bosses to agree that spending time refactoring so-so code (that works!) is worth $XXX/hr, it's no surprise she's getting frustrated. in my mind, her role as a developer is to apply sound theory as much as possible within the constraints of her job. when other people are signing her paycheck, she either does it their way or finds a new job (or applies to YC)--but complaining about it won't help her situation.
when other people are signing her paycheck, she either does it their way or finds a new job
If the people who hired her were thinking straight, they hired her for more than just her ability to write code to a strict specification under strict supervision. A number of developers are valuable far beyond their ability to make a computer do their bidding, and the employer who does not care does so at their own peril.
She may come off as a little overbearing, but I don't get the sense that she is unreasonably set in her ways. I get the sense that she's passionate about doing things right, and will take up issue when something doesn't make sense and push back until things do make sense. If you think these are the same, I'm afraid your model of developer behavior is flawed. Strong beliefs can be weakly held.
And it is possible that refactoring code that works is worth $XXX/hr. Consider the savings that might be accrued later on due to shorter bug-fix cycles, quicker feature releases, and less overall malaise of the development staff. Not everyone can be motivated by having their paycheck treated as a carrot on a stick. So the money might be very well spent.
If the people who hired her were thinking straight, they hired her for more than just her ability to write code to a strict specification under strict supervision. A number of developers are valuable far beyond their ability to make a computer do their bidding, and the employer who does not care does so at their own peril.
She may come off as a little overbearing, but I don't get the sense that she is unreasonably set in her ways. I get the sense that she's passionate about doing things right, and will take up issue when something doesn't make sense and push back until things do make sense. If you think these are the same, I'm afraid your model of developer behavior is flawed. Strong beliefs can be weakly held.
And it is possible that refactoring code that works is worth $XXX/hr. Consider the savings that might be accrued later on due to shorter bug-fix cycles, quicker feature releases, and less overall malaise of the development staff. Not everyone can be motivated by having their paycheck treated as a carrot on a stick. So the money might be very well spent.
eloquent strawmen aside, i don't disagree with your points. i just think that if the people who hired her thought the way you do, she wouldn't have posted in the first place. but, they don't, so she did.
There's a chasm you have to cross to become "senior", whatever that means. One of the biggest skills you need to learn is not technical. That skill is understanding exactly how to apply our limited resources.
Should we worry about how well a certain module was written? Maybe, maybe not. Sometimes the answer really is, "It runs well and isn't hurting anything, so let's leave it alone. Opening up that can of worms dumps 47 new issues into our queue and now is not a good time to do that." Or the answer may be, "This has to be made right before we can add these 27 other things to the system or we'll all be in deep sh*t." How do you know which? Experience. Understanding the big picture. Understanding your customers and users. Understanding your dev team. You get the idea.
Taking on a lead role is not selling out if it's used to expand your horizons and make you an all-around better dev person. When you return to full time development, you'll be light years ahead of those who never had to manage the whole project. A little perspective goes a long way.
Should we worry about how well a certain module was written? Maybe, maybe not. Sometimes the answer really is, "It runs well and isn't hurting anything, so let's leave it alone. Opening up that can of worms dumps 47 new issues into our queue and now is not a good time to do that." Or the answer may be, "This has to be made right before we can add these 27 other things to the system or we'll all be in deep sh*t." How do you know which? Experience. Understanding the big picture. Understanding your customers and users. Understanding your dev team. You get the idea.
Taking on a lead role is not selling out if it's used to expand your horizons and make you an all-around better dev person. When you return to full time development, you'll be light years ahead of those who never had to manage the whole project. A little perspective goes a long way.
How do you know which? Experience.
I wish I were learning it was even that easy. Maybe it is, and I'm just thinking about it too hard.
To borrow your analogy of the can of worms module, that it runs well but will become a bomb as soon as someone decides to rewire it fills me with a sense of deep dread. My mind immediately drifts to the scenario where something forces changes on that module, such as the server continuously crashing due to a latent schrodinbug that just surfaced, but in a time-frame where those 47 issues just can't be resolved. I've never been comfortable with the justification that "it works now, so just don't screw with it." It seems to just be begging for Murphy to make a fool of the person justifying a decision thusly.
I used the analogy of technical debt being called in a post a few months ago to describe this situation. Granted, my experience as a developer is still somewhat limited, but I have seen people with years of experience get completely hosed by deciding wrong; sometimes deciding wrong a lot. I've also seen people with just a couple of years of experience pick the way to go with decent accuracy. This makes me wonder if there is an intuition certain people have that experience hones, but that experience alone does not completely replace.
I wish I were learning it was even that easy. Maybe it is, and I'm just thinking about it too hard.
To borrow your analogy of the can of worms module, that it runs well but will become a bomb as soon as someone decides to rewire it fills me with a sense of deep dread. My mind immediately drifts to the scenario where something forces changes on that module, such as the server continuously crashing due to a latent schrodinbug that just surfaced, but in a time-frame where those 47 issues just can't be resolved. I've never been comfortable with the justification that "it works now, so just don't screw with it." It seems to just be begging for Murphy to make a fool of the person justifying a decision thusly.
I used the analogy of technical debt being called in a post a few months ago to describe this situation. Granted, my experience as a developer is still somewhat limited, but I have seen people with years of experience get completely hosed by deciding wrong; sometimes deciding wrong a lot. I've also seen people with just a couple of years of experience pick the way to go with decent accuracy. This makes me wonder if there is an intuition certain people have that experience hones, but that experience alone does not completely replace.
"To borrow your analogy of the can of worms module, that it runs well but will become a bomb as soon as someone decides to rewire it fills me with a sense of deep dread. My mind immediately drifts to the scenario where something forces changes on that module, such as the server continuously crashing due to a latent schrodinbug that just surfaced, but in a time-frame where those 47 issues just can't be resolved. I've never been comfortable with the justification that "it works now, so just don't screw with it." It seems to just be begging for Murphy to make a fool of the person justifying a decision thusly."
Yes, so you make that part of the decision. It's all contextual; you can fiddle with this hypothetical this way to make it 'yes', you can fiddle with it the other way to make it 'no', and both hypotheticals will be simplified to the point of irrelevance compared to any real situation that may arise.
Yes, so you make that part of the decision. It's all contextual; you can fiddle with this hypothetical this way to make it 'yes', you can fiddle with it the other way to make it 'no', and both hypotheticals will be simplified to the point of irrelevance compared to any real situation that may arise.
I don't know if it's so much intuition as it is luck (or, heh, being unlucky). I seem to have an uncanny knack for spotchecking one thing, and while I'm doing that, uncovering a bunch of other problems because something in the things I've chosen to spot check has an association with something that looks wrong. Like, I'll spot check a database update, and I'll display all columns even though I am only looking at one or two. It just so happens that in the rows I chose to check, another field is obviously not being validated right.
I've also experienced some weird premonitions, like I'll suggest a change be made, based on some trend I may be seeing but can't articulate, and then a few days later the very thing I suggest should be changed needs to be changed, usually under time pressure.
I wish I could bottle and sell this, but I'm sure it's closer to being unlucky than having a superpower (like Rob McKenna from HHGTTG), and no one would want it.
I've also experienced some weird premonitions, like I'll suggest a change be made, based on some trend I may be seeing but can't articulate, and then a few days later the very thing I suggest should be changed needs to be changed, usually under time pressure.
I wish I could bottle and sell this, but I'm sure it's closer to being unlucky than having a superpower (like Rob McKenna from HHGTTG), and no one would want it.
When I said "experience", I was trying to differentiate between a capable person who hadn't done much with one who had been around the block a few times. It's usually easier for the second person to avoid pitfalls and use all of their resources to make a good decision.
Adding experience to a person who is not smart or capable, stubborn, lazy, or has other personality "issues" is generally a waste of time and resources. Looks like you've met a few of these people. Most of us have.
Adding experience to a person who is not smart or capable, stubborn, lazy, or has other personality "issues" is generally a waste of time and resources. Looks like you've met a few of these people. Most of us have.
That skill is understanding exactly how to apply our limited resources.
That skill is called management.
That skill is called management.
[deleted]
"It's extremely frustrating to work with individuals and in scenarios such as these. [...]
My strong point is that I communicate well with people, and I'm not afraid to take an issue up with someone"
Reminds me of Office Space: "I've got good people skills, damn it!!!"
My strong point is that I communicate well with people, and I'm not afraid to take an issue up with someone"
Reminds me of Office Space: "I've got good people skills, damn it!!!"
They seem to encourage the original poster to adopt a short-term, sycophantic perspective where she punts her desire to keep the code-base clean and maintainable in exchange for blindly following requirements and putting forward a good image. I know there are a certain class of people who recoil in instinctive disgust at the suggestion, even after being reasoned with and beaten down; I am one of them.
One of the posters even mentions the books that talk about this sort of thing, and then dismisses them as irrelevant to the true goals of management. Most of these books contain the wisdom of people who have seen many projects and products, and have a reasonable idea of what makes one successful from a technical stand-point. The reason they were written is because the authors saw enough projects fail when not following the practices they suggest. It isn't just wishful thinking written by technically minded trolls.
Reading all these comments I am reminded of the first section of a book I read recently which helped me realize I wasn't alone. I believe I have mentioned it on here in a prior post; Uncle Bob's _Clean Code_. One of the most salient points he makes in the first chapter is that the quality of the code-base is the responsibility of the developers, because they are the only ones who have the most concrete sense regarding the cost of bad code. In the long run, it will make everyone look completely incompetent, even if in the short-term things appear to be getting done at a very rapid rate. Eventually, your clients will care, your managers will care, and “I was just following orders” will not be an acceptable excuse because they were looking to you for intelligence and wisdom, not just units of work done without deep analysis.