|
Am I a unique hybrid?
I really enjoy the challenge of:
A. understanding the problem domain,
B. designing a solution to fit the problem,
C. implementing the solution,
D. and maintaining the solution.
I enjoy owning the process from top to bottom. Typically, project managers are entrusted with the top (A & B), while software developers are responsible with the bottom (C & D). Project managers typically deal in the domain of "what to do", while programmers deal with "how to do it".
I currently have two applications projects within the company I work for. Although the projects are small (I'm the only developer), they're significant and respected throughout the entire company. With one of my projects I have full and complete ownership. I'm not only the programmer, I'm the project manager. I really like this. With my other project I'm only the programmer. I'm not given free reign with "what to do", but I am given free reign with "how to do it". I'm really frustrated with this second project.
I don't like being handed a spec and only having authority over "how to do it". I also want to have authority over "what to do" as well. And I've proven that I can do well in both arenas. So my question, am I a unique hybrid of project manager and software developer rolled into one? Or are most programmers like me? Are there actually people who *like* being handed a spec and told to just do it? Are there people who like thinking about the problem at a high level, and letting others work out the details? How does a seeminly unique person like me fit into a corporate environment? Or should I just quit and start my own company? :^)
Curious George
Sunday, December 7, 2003
Curious,
You're normal, or what should be normal.
What do you call a programmer who says:
* "the customer keeps changing the spec"
* "give me a spec, and I'll code it"
* "that's the PM's job"
Call him "useless".
@cha
Monday, December 8, 2003
That's not unique, it's something I've done from time to time and it is a lot more fun (and humbling too) than just getting a spec and coding it. However, there are a lot of developers I've met that see their position as that of creating code based on a spec (and, by and large, wish the users/clients would make up their damn mind). Hmm, maybe this relates to the "coding as a low-skill" thread...
From the company viewpoint... On one hand there is the paranoid management case: regulations and control points are necessary, and a coder should code and a consultant should gather requirements. On the other, efficiency: instead of a requirements "middleman", you get faster design/development and some aspiration to RAD. One of the places I worked actively supported the growth of manager/developer hybrids that you describe.
Bottom line: A developer who can speak a human language as well as a technical language is a lot more useful than one who who only speaks the latter.
Shodan
Monday, December 8, 2003
I agree, that desire is what should be normal.
It's both sides of the coin as I see it:
* Responsibility to deliver a product
* Authority to do what needs to be done to make it happen
If you're only a developer, you have the first, but not the second. If you're only a project manager, you have the second but not the first.
I think most people are less stressed when they don't have obstacles to them achieving their job.
Sum Dum Gai
Monday, December 8, 2003
I am with you. The projects that I like the most are where I feel like I have ownership of the product. That means being involved in everything from talking to clients, to designing the app and what features it should have, to coding and maintaining it.
Being just a hired to be a code jockey is no real challenge and not much fun.
Craig
Monday, December 8, 2003
I'd use the word "special" rather then unique. I think this makes you a valuable asset to the company you work for. I have a problem that I need to fix, and thats not finishing and maintaining something. I'll research, design, implement, but I *hate* doing minor improvements and maintenance. Maybe its the lack of urgency, or my own ego saying i'm too good for it, but it is a weakness. Many people have a weakness similar to this, wether it be they have trouble starting a project, or finishing it, or maintaining it.
vince
Monday, December 8, 2003
That's pretty much my job description, too. I don't know how usual it is, but you're not unique :-)
Fernanda Stickpot
Monday, December 8, 2003
I hate D when I had to do a rush job on A,B and C.
Just me (Sir to you)
Monday, December 8, 2003
It is not unique and I suspect a lot of people would like to be in that position, even though sometimes other pressures conspire against them.
I would say that it is an ideal, where the project is small enough to fit one person doing it. It becomes non-trivial as the project grows, as co-ordinating the effort with other players/projects begins to take up a significant amount of effort.
In relation to the low-skills thread, I would say that anyone who doesn't at least aspire to do A-D (as you put it) should expect their job to be offshored some time soon.
It is true that simply coding from a spec is often a low-skill job. I've done that sort of thing where the project manager literally referred to the coders as his "production line".
Where you can really add value is in working closely with the people who actually do the work, understand their job (and their pressures), talk their language, then just get on with building something that will make their job easier. Most businesses have labo(u)r costs as a large chunk of their expenses, so saving time means a big impact on the bottom line. This sort of work is not possible to offshore as you need to be in there, not thousands of miles away, in a different time-zone and continent.
Just my USD0.02.
Steve Jones (UK)
Monday, December 8, 2003
Thank you all for your comments. I don't feel so alone. :^)
What is a good job title for one who performs both product management and software development? It needs to be something that communicates clearly to management. (ie. next job review I can say that I'm ready to be a "xxxx" on all future projects.)
Curious George
Monday, December 8, 2003
Curious George, instead of attributing uniqueness to your abilities, why not assign value instead? What you state that you do is HIGHLY valuable.
However, what you state that you do also will not be believed by many organizations that are merely looking for a code monkey. Or, it will be viewed as subversive.
In most companies, project management functions and implementation are segregated strictly by personnel role. If you want to wrap your arms around the entire project and make that a point in your interviewing, you will be rejected by a certain (high) percentage of organizations that view the cross-talented programmer as a burden.
Ultimately, my guess is that you will have to either get a principal position in a small growing company in order to be able to use your abilities, or you will wind up starting your own consulting business.
Bored Bystander
Monday, December 8, 2003
I have found - to my disappointment - that as time goes on and as more projects are completed, the increasing amount of time spent on maintenance squeezes out the time spent on A, B, and C.
Devil's Advocate
Monday, December 8, 2003
+1 for "subversive"
And to answer the question of whether there are people who only care about how to do it and not what to do -- yes, I work with some. One of them, I'll admit, is a better engineer and OO designer than I am. (Thankfully for my ego, I don't really think of those as my primary skills.) Just don't ask him to write a requirements doc. And even once you've decided what to do, if you don't have time to rewrite the database, redesign the zip file, or write an OCR engine, you have to say so loudly and repeatedly.
I really don't see anything wrong with being only interested in one part of the process. I mean, this guy's one of my favorite coworkers, because A) he's part of the 1% talent-wise and B) he respects the importance of the other parts and appreciates it when they're done well by someone else.
Mikayla
Monday, December 8, 2003
DA,
We have seen this problem creeping up at our company. It's an easy answer to give the new hire something new to work on because the existing staff are too valuable maintaining the existing products.
In the past, the management wanted to hire a "maintainence programmer" not realizing that no competent person would take the job. We've come to the compromise that the new folks must start with getting up to speed on maintainence so that the more experienced people get to work on new projects.
pdq
Monday, December 8, 2003
I've find that by doing maintenance (D), I learn how to do A, B and C better. IMHO, if maintenance is to be assisted by another programmer, it should be under the close management of the primary programmer. Otherwise, too much good feedback from the field can get lost on others who don't know how it fits into the big picture.
Curious George
Monday, December 8, 2003
Hi Curious George,
Imo this is a good post. I don't have the time to respond to your questions. However, if you are interested in reading more about some of the questions you brought up you might want to check out the following:
Role Fragmentation http://www.softwarereality.com/lifecycle/role_fragmentation.jsp
The Rise and Rise of IT Administrators
posted within Slashdot's programming section
One Programmer's Opinion
Monday, December 8, 2003
Yes, you are unique. Just like everyone else.
Monday, December 8, 2003
>I don't like being handed a spec and only having authority over "how to do it". I also want to have authority over "what to do" as well.
Consider yourself lucky.
Me and my colleagues are often given plenty of advice on "how to do it", but remarkably little information on "what to do". Been there ?
(Well, in the end, we decide what to do and how to do it. And get the blame for it ;-).
Otherwise, in my experience, being handed a spec does not mean you're going to code. Far from it. You're going to interpret the spec (read: rewrite entirely, unless your organisation includes professional spec writers). You're going to make the design. You're going to correct the spec. Then you're going to program, and eventuelly you correct the spec.
Pakter
Monday, December 8, 2003
I do understand that traditionally maintenance was a bad thing. But since the advent of refactoring, maintenance is fun! Do people still see maintenance as drudge work?
Tony Chang
Monday, December 8, 2003
There's a big difference in "fix this bug" and "rewrite this code to be better".
Most of the time, maintainence is on the "fix this bug" side.
pdq
Monday, December 8, 2003
Certain DOD follow-on work is the penultimate in polishing the proverbial lump of feces.
A contract is let by a branch of the services to add features X,Y and Z to the existing macho-named green and camo painted hardware device. Because bids are won competitively (cheapest wins), there is NO money allocated to refactor existing code.
So, the code in a system that has been a subject of several DOD "enhancements" is usually a steaming pile of offal. Global variables, flags and other kluges are used to patch around limitations in the baseline code, because any refactoring type operation is "out of scope".
Bored Bystander
Monday, December 8, 2003
Tony Chang, I think a lot of us are still having to deal with 'traditional maintenance'. i.e. the reactive type.
Proactive refactoring is something that needs manager buy-in. As Bored comments, a lot of this comes down to money. And if code is changing hands all the time, no-one wants to take the hit for that.
Shodan
Monday, December 8, 2003
Mikayla,
Does your colleague have a problem with a moving target spec? Just curious.
Shodan
Monday, December 8, 2003
"What do you call a programmer who says:
* "the customer keeps changing the spec""
Someone who i going to miss the original milestones.
Tuesday, December 9, 2003
'There's a big difference in "fix this bug" and "rewrite this code to be better".
'Most of the time, maintainence is on the "fix this bug" side.'
Most of the time, these two things are the same. After all, if the code around the bug isn't refactored to be more robust, it will just blow down again the next time there's a light breeze.
In the last couple of years at least, I've only once fixed a bug without doing what I thought were necessary rewrites, and that was when I was desperately pushed for time. The rewrite is on my list.
Fernanda Stickpot
Tuesday, December 9, 2003
Well this is interesting. I'm glad I'm not in a situation where fixing the underlying problems that are leading to a preponderance of bugs is 'not allowed.'
The thing about it is that in the medium to long term, refactoring is not only necessary but cheaper.
It's also safer. I wonder how many soliders die because the lowest bidder software in their Apache helicopter failed due to code rot? Wow - I really had thought the military had better safety standards. Don't let the soldiers know we don't care if they live or die as long as we save a few pennies on the development in the short term.
I sure wouldn't want to drive a car or put my money in a bank where all the bugs were patched with quickie global variable shunts by whatever guy was available at the time.
Anyway gettnig back to the post, yeat for sure if maintenance just involves putting out nonfunctional junk, then I can see how it would be a very depressing line of work.
But maintenance where you make the code better is actually fun. I guess it's a sad testimony to the industry that the common wisdom is that this is a waste of time.
It comes back to bite them though -- every cheap fix comes with its own set of problems and the maintenance guy will be back over and over again fixing the same problems with the code over and over again if he doesn't fix the underlying problems instead of get hooked on the cheap fix. Very quickly, these costs far surpass even modest estimates of what a bare bones refactoring
would get you, while delivering far less value than that refactoring would.
Penny wise and pound foolish as they say.
Tony Chang
Tuesday, December 9, 2003
"I sure wouldn't want to drive a car or put my money in a bank where all the bugs were patched with quickie global variable shunts by whatever guy was available at the time."
And how, pray tell, would you know what development methodology your bank or car maker uses?
You could be doing those very things right now.
Scary isn't it! ;)
Sum Dum Gai
Tuesday, December 9, 2003
Great thread.
WHY SKILL SEGMENTATION IS A PROBLEM
I think the problem with "skill segmentation" is that software development (like any complex problem solving) is ITERATIVE.
You define a goal, then work on it a bit, learning more about the solution. This may illuminate something that may change the goal.
In software dev, you might develop a prototype and show it the customer, who then realizes they need it to be different.
AND I THOUGHT IT WAS JUST ME
This drove me nuts at several places I worked. I figured I was just a control freak, so I started my own software company. After much success, I can look back and realize that I wasn't (necessarily :-) a control freak, I'd just REALIZED that this process is iterative.
WHERE EGOS FEAR TO SOAR
Heck, there are times that *I* will define a problem and then solve it to completion and then realize that the problem was poorly defined. I can be honest with myself and learn to NOT do that anymore. Most companies I've worked for make those same mistakes, but EGOS prevent them from articulating the problem or even recognizing it.
Entreprenuer
Tuesday, December 9, 2003
"Am I a unique hybrid? "
No. You're just being an idiot.
Utopia is a place where no moron exists
Tuesday, December 9, 2003
>> It's also safer. I wonder how many soliders die because the lowest bidder software in their Apache helicopter failed due to code rot? Wow - I really had thought the military had better safety standards.
Unknown. But believe it that programs like Pavehawk contain software deliverables that consist of spaghetti coded procedural code written 20+ years ago, twiddled endlessly by an ever-changing cast, and ported between processors one or two times in the interim. Another factor at work in DOD stuff is that software technology is often not respected at all. Only the guys making the green metal boxes are thought to be creating value.
Since quality by construction is not possible when the customer demands cheapness, I think the DOD mainly relies on "exhaustive" testing to assure quality. Of course, they can't possibly exploit every potential race condition.
I worked at a DOD contractor that considered OOP to be exotic, consumer and gamer type fare, and their most senior SW developer on staff didn't understand where function value parameters in 'C' code lived... The management pretty much expected software development to consist of managing spaghetti. They considered it necessary and couldn't imagine any other way.
Bored Bystander
Tuesday, December 9, 2003
 Recent Topics
Fog Creek Home
| 
