I had a really devious thought the other night. It's totally hypothetical, but it fits so well into the conspiracy theory mindset that I had to put it out for kicks.
The rise of outsourcing/offshoring in IT around 2000 caused great concern in the developer population, because we saw our livelihood disappearing. About 2004, a number of reports surfaced that claimed that IT/Software jobs would return, due to 2 things - the rise of the local job demand in the offshoring nations, and the retirement en masse of the large number of Baby Boomer developers, enjoying their retirement money, bouyed by the growing housing market. This would drastically cut the number of working developers, forcing the companies that employ them to raise salaries again, like in the dot-com boom.
This year, the housing market collapsed, taking out a large segment of the stock value. This destroyed the value of a majority of the retirement accounts of all these soon-to-retire developers, making them more likely to stay in the workforce, keeping the numbers high, and salaries low.
The greatly wealthy were not hard hit by this collapse; after all, losing 75% of 4 billion (the amount George Lucas was worth) still leaves you with 1 billion. [Note - I don't think George was in on it, he's just a well-known individual]
But having your 401k drop from $1M to $250K means you will probably have to keep working, and your best work is that which you've been doing for the past 30 years.
It will be interesting to see how this plays out.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, December 29, 2008
Friday, December 19, 2008
Letting Your Developers Excel
As every developer knows, it's hard to soar with the eagles when you're surrounded by turkeys. And by turkeys I don't mean your cow-orkers, but your environment.
As 37signals, and Jeff Atwood describe, a workplace that doesn't trust you, or won't provide necessary equipment won't let you achieve your best.
Now, it's hard to make your bosses extend more trust to you, but you can gain some of the same effects by skunkworking your situation - firewall your development environment from management; extend your estimates a little; frame the dialog with management in your terms - ask what they want as the end result, not how they want it done.
Budgets make technology stuff harder, but use Jeff's numbers to show how quickly your purchases will pay for themselves - show your compile times, the time spent switching workspaces instead of having 2 monitors, and show how the better equipment will help them.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
As 37signals, and Jeff Atwood describe, a workplace that doesn't trust you, or won't provide necessary equipment won't let you achieve your best.
Now, it's hard to make your bosses extend more trust to you, but you can gain some of the same effects by skunkworking your situation - firewall your development environment from management; extend your estimates a little; frame the dialog with management in your terms - ask what they want as the end result, not how they want it done.
Budgets make technology stuff harder, but use Jeff's numbers to show how quickly your purchases will pay for themselves - show your compile times, the time spent switching workspaces instead of having 2 monitors, and show how the better equipment will help them.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, December 17, 2008
Burnout
I'm suffering a bad case of burnout. Work has been a lot of conflicting bug fixes, nearly one hundred arbitrary deadlines, every release getting patch branches, and it's gotten me down. The work is too simple and too rushed to be satisfying. The matrix management has all the managers giving me "top priority" tasks, each wanting their own to be really top priority. Other development teams are trying to obsolete portions of our product. Customers are pushing their systems past all reasonable limits because our marketing dept did not push back.
In short, I'm sitting in the middle of a big helping of Life Sucks right now.
My hope is that the holidays will get me some much-needed sleep and downtime, and I will start up out of the pit.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
In short, I'm sitting in the middle of a big helping of Life Sucks right now.
My hope is that the holidays will get me some much-needed sleep and downtime, and I will start up out of the pit.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, December 15, 2008
No Comment!
Comments - a contentious subject
Every developer has horror stories of the monster codebase without comments, or worse yet, the one with misleading comments.
And last July I saw this - Jeff Atwood advocating coding without comments. When I see these sorts of articles, I wonder how many multi-developer. multi-process systems the authors have worked on. While I agree that it's hard to work on code with bad comments, if the code has seen several developers, the comments may be all that exists to explain why things are being done.
Jeff's example is relatively trite - code that implements math functions is almost by definition clear in intent. If you have a function that implements business logic for a niche industry that will not have a clear meaning to a new developer, or a seasoned one that has been away from the code. And that's the reason comments are necessary - no matter how good the other documentation may be, the developers will be in the code first, so that's where you need to have the most info useful to programmers.
So when you are coding, add comments that explain the logic behind the code. Most of it might be doable with correctly-named function names, and variables, but some things are not so easily explained and need a paragraph or two to get that across.
Not this:
a++; // increment a
But this:
a++; // the hardware uses 1-based numbering
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Every developer has horror stories of the monster codebase without comments, or worse yet, the one with misleading comments.
And last July I saw this - Jeff Atwood advocating coding without comments. When I see these sorts of articles, I wonder how many multi-developer. multi-process systems the authors have worked on. While I agree that it's hard to work on code with bad comments, if the code has seen several developers, the comments may be all that exists to explain why things are being done.
Jeff's example is relatively trite - code that implements math functions is almost by definition clear in intent. If you have a function that implements business logic for a niche industry that will not have a clear meaning to a new developer, or a seasoned one that has been away from the code. And that's the reason comments are necessary - no matter how good the other documentation may be, the developers will be in the code first, so that's where you need to have the most info useful to programmers.
So when you are coding, add comments that explain the logic behind the code. Most of it might be doable with correctly-named function names, and variables, but some things are not so easily explained and need a paragraph or two to get that across.
Not this:
a++; // increment a
But this:
a++; // the hardware uses 1-based numbering
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, December 14, 2008
Passion - Do You Have It? And For What?
When you have passion for your work, it hardly seems like work - you want to solve the problems in front of you. You get a kick from constructing the solution in code.
The dark side of passion is that it often get used as a club to convince you to work long hours under bad conditions because doing otherwise is "unprofessional" - if you are professional, you are supposed to love the work.
Bull. You are professional if you hate being made to ship unfinished product just because someone in Sales needed a bigger bonus this quarter, so they pulled in a deadline. You hate working overtime to fix bugs that made it to the field because of those rushed releases.
Over on Creating Passionate Users (apparently defunct) is a post about this topic, and although it is written more for game developers, it rings true. Passion should not be getting you to do things you don't like; it should be getting you to do things you love.
So look around at your job, and see if you can find the passionate developers - and you will find they are not the ones who don't care about working overtime, just to be seen as "team players" - they're the ones who prefer to make their code better so that they rarely need to work overtime.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The dark side of passion is that it often get used as a club to convince you to work long hours under bad conditions because doing otherwise is "unprofessional" - if you are professional, you are supposed to love the work.
Bull. You are professional if you hate being made to ship unfinished product just because someone in Sales needed a bigger bonus this quarter, so they pulled in a deadline. You hate working overtime to fix bugs that made it to the field because of those rushed releases.
Over on Creating Passionate Users (apparently defunct) is a post about this topic, and although it is written more for game developers, it rings true. Passion should not be getting you to do things you don't like; it should be getting you to do things you love.
So look around at your job, and see if you can find the passionate developers - and you will find they are not the ones who don't care about working overtime, just to be seen as "team players" - they're the ones who prefer to make their code better so that they rarely need to work overtime.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, December 13, 2008
A List I Need To Re-read Soon
One of the hazards of developing for a large company is that you tend to fall into a niche, due to the managerial wont for having "Experts" on parts of the system easily identifiable and accessible. So you get more of the work on the parts you know well, because you can solve probelms faster (for field issues) and can plan faster (for new development).
The downside of this is that you can lose sight of how your skill set really maps up to others, because you're working in an area where you are supported by your background knowledge, as opposed to your programming skill.
I'm feeling this lately, since I've been stuck in customer support Hell for a while. So when I consulted with a cow-orker about an issue, and determined that code I was working on was exhibiting signs of voodoo programming (No chickens were harmed in the production of this code), I was reminded of this list. It's a little tongue-in-cheek, but it has points to ponder.
Too often we forget to revisit the basics of the craft - or time pressures make us fall back to old code practices that are not so good anymore. So take some time this holiday season to look at your skill set and see if you could use some polish in the basics.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The downside of this is that you can lose sight of how your skill set really maps up to others, because you're working in an area where you are supported by your background knowledge, as opposed to your programming skill.
I'm feeling this lately, since I've been stuck in customer support Hell for a while. So when I consulted with a cow-orker about an issue, and determined that code I was working on was exhibiting signs of voodoo programming (No chickens were harmed in the production of this code), I was reminded of this list. It's a little tongue-in-cheek, but it has points to ponder.
Too often we forget to revisit the basics of the craft - or time pressures make us fall back to old code practices that are not so good anymore. So take some time this holiday season to look at your skill set and see if you could use some polish in the basics.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, August 02, 2008
Who are you likely to be working with?
Last Wednesday, after looking at a process module written by a cow-orker that was totally alien to any of the codebase we have, I was reminded of the words of a former boss - "Don't be clever". His point was that if you are being clever, you are making things hard to understand, and that makes the code harder to work with. This post makes the same point, near the end, when discussing exceptions and execution flow. The odds are great that your fellow programmers are NOT the geniuses being hired by Google, or running a startup funded by Y-Combinator, so you need to write your code so that it is easy to understand and debug.
You also need to write programmer documentation in the CVS system, so that the next developer does not have to hunt it down in whatever document storage system you use - it needs to be write next to the code, and it needs to be clear.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
You also need to write programmer documentation in the CVS system, so that the next developer does not have to hunt it down in whatever document storage system you use - it needs to be write next to the code, and it needs to be clear.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Posts (Atom)