I don’t like being completely alone. I don’t want to be the only one responsible over whether a project will succceed, esp. when someone else who knows nothing about programming is repsonsible for gathering requirements.
I’d love to work in a team-oriented environment, but I don’t think non-programmers knows what that means. Working with a team certainly does NOT mean working side-by-side with your peers all day long which is how managers seem to think of a “team”. It’s best to work alone most of the time, but have regular meetings every day or two to discuss progress, requirements, design, etc… and use email / IM for quick questions so you don’t disrupt anyone else’s concentration at inopportune times. That’s another thing managers don’t understand - the importance of not being distracted when your “in the zone”.
Oh, and Fred… most software is not engineered. Safety-critical systems are, but not websites, games, media software, etc… Software development is still a craft, because its more about exploring, tinkering, and just playing around with code until it works. Engineering implies that you can write extensive design documents describing every last detail of every feature before you begin to write code, and it’s proven that’s extremely impractical.
@Fred on June 16, 2008 05:38 AM
" It can be right or it can be wrong. There is no in between. "
That’s where you’re wrong. It’s not about whether a component works or doesn’t work, it’s about how well it works. It’s about how efficient and clearly written the code is, the level of abstraction, and about it being highly-cohesive and loosely coupled. This is why software development requires a mind that can appreciate the beauty of elegant algorithms and architectures.
I think part of the reason programmers are reluctant to show any thing less than “perfection” (in their own mind) comes from my observation that so many of people in this industry are arrogant, self-righteous jerks.
Seriously. Put yourself in this position: Everyone you work with believes they were the best thing to ever happen to computers. They present themselves as infallible, knowing everything, and producing bug-free, perfect code in less than human time. They’re never wrong, and if they’re ever proven wrong, it’s obviously not their fault (sarcasm).
In this position, wouldn’t you be a little self conscious too? You have to be pompous and perfect just to keep up with everyone else!
I like to think that the world knows those arrogant people are wrong about themselves and the work they produce, but sometimes I’m not so sure… They sure seem to get a lot of respect and glory, everywhere I go.
Most projects require teamwork. Sometimes there IS a specific problem where you want the resident genius to lock him/herself in a room and not come out until problem solved.
An open source project is a very different animal. It’s a motley collection of widely distributed, loosely coupled volunteers. There’s no project manager breathing down your neck, urging you to break your work into short, shareable increments. The risk of going dark is severe.
Sure, there isn’t a project manager breathing down your neck. But open source projects most certainly do have so-called “maintainers” (i.e. those people who both have access and permission to commit to the code of the main development line). Thus, what for closed source software (not necessarily commercial) is the job for the project manager(s), becomes part of the project maintainer’s job in open source software.
How do you expect your fellow coders to take you seriously if you aren’t regularly showing them code? It’s the only form of currency that matters on an open source project.
Exactly! And this very fact gives the project maintainers some form of “power” to demand that submitted patches are delivered as small and digestable incremental changes. You wouldn’t want to go through a large amount of effort writing a patch only to get it rejected now would you? Especially not if the code (and perhaps the “ego-boost” associated with it) itself and the time spent on it is the only currency.
For example, we at Warzone 2100 ( http://wz2100.net/ ), i.e. the project maintainers, as a policy request submitted patches to be small and incremental. Small and incremental patches always get priority, not because they’re more valueable, but simply because they’re easier to understand and thus to apply. Furthermore I, in the role of a project maintainer, quite consistently reject patches that are too large to understand well enough. I almost always request patches to broken down in smaller pieces if I consider them to be too large. If I like the feature or behaviour change of a patch enough, (or like the developer that wrote it enough), I may perform this patch splitting myself. In all cases though, I only commit patches that are small enough so that each changeset is fairly easy (for those who’re familiar enough with the code already) to grasp.
As dev of the open source RTS game engine Spring I’ve experienced all these disadvantages. Besides the issues you mention in your post there’s also the fact that submitting a huge blob of code to a project often attracts a lot of compliments from the non-programmer people (in case of Spring: players content developers) in the community.
This alone already increases pressure on the project developers to commit the code as soon as possible by a huge amount, while at the same time there seems to be a strong negative correlation between size of the initial patch and code quality (there are exceptions of course).
Combined this makes that reviewing, fixing and integrating these huge blobs of code is a very costly (in terms of time) and risky operation, which also isn’t as easy to cooperate on as when it had been made in small chunks. In practice I observe this means it takes ages before huge patches are entirely integrated, if they get integrated at all.
I just had to pipe up and say that I actually have the same situation as Niels, I’ve been at two jobs now where I couldn’t get people to review my code for anything. On the rare occasion that I did get feed back, the reviewer only found a few misspellings in my comments… The few times in school when we had code reviews, I actually loved it. It was great having someone willing to discuss various quirks in my code or how things could be done better.
In this position, wouldn’t you be a little self conscious too? You have to be pompous and perfect just to keep up with everyone else!
This.
The first thing you’re told in industry is “you don’t have experience”. You could have been a hobbyist programmer for 10 years, learning and making all the rookie mistakes (and learning how to aviod them in the future), feeling confident in your ability to contribute to the world. However, because you don’t immediately know exactly what the company is doing, everything about the tools used (which change every 2 years), and everything about what is done in the background, you are dismissed as an inexperienced hack, knowing nothing. Going dark is just a way to cope with the politics of being the noob who has to prove yourself. (The only other way to do it is to accept your worthlessness and become a voiceless corporate drone - this isn’t exactly an appealing path to everyone).
Another thing to note is that software isn’t a right/wrong proposition. Design isn’t a right/wrong proposition - it’s about tradeoffs between flexibility and ease of use. You choose a design depending on which you want to maximize. When you get other people in the fray, you run the risk of getting into fights about what to maximize/minimize, what would be easiest for the user, etc. Furthermore, you as an individual are less likely to feel joy in your creation, as it is no longer yours.
For some people, software is a vehicle to make money; for these people, going dark is detremental, as it disconnects you from communication with your customer base.
For others, software is a vehicle to prove their worth to society - to express something. Doing anything but going dark is detremental, as it disconnects you from your ability to truly prove yourself.
Speaking of edge-cases, what do you do when, like me, you work for a tiny start-up and you’re programming in at least six different languages (in my case, Ada, Assembler, BASIC, C, Delphi, Fortran, Perl and VBScript)? Okay, the CTO reviews my code from time to time, but we just don’t have the man-power for consistent checks. And it’s proprietary code, though as has been pointed out, even open source isn’t necessarily any better off.
I’ve found in the business world this can be measured in two areas:
1 - How fast you want the project done
2 - How easy you want support to be
So for #1 if you just lock the programmer in their cube until the project is done with very little outside interaction or code review, they will finish faster and usually make a good project. But in that case your #2 will be a major pain, especially if you have other people supporting code they didn’t write.
If you do a lot of intensive team code reviews then support should be easy, but your project timeline will be in the gutter.
In my recent performance review, I actually asked for more code reviews. That’s because I know myself. And I know at the end of a day when I’m tired I am going to do something stupid.
But I know that if someone else is going to be looking at my code, two things happen.
I have a backstop to catch me, thus reducing the pressure and stress to get everything perfect.
It also reminds me that someone at some point is going to look at my code and I don’t want them to think “What the heck was he thinking!?”
Just like to add that 99% of the project I worked on was coding in C; surely people pointing out flaws and blind alleys in your code forces a redesign otherwise what’s the point?
You are the living proof that Jeff is too busy to read all the posts.
An idea: Jeff must write an article about the difficulty of reading all incoming posts while writing new articles… (Gdel, get out of my mind right now!)
I have to admit that this is one of the reasons I don’t try my hand at open source programming. I understand the need for code review. In fact one of my co-workers and I review each others code all the time. As a young programmer I find it a great way to learn.
It’s the people who act like they have never wrote bad code that keep me wanting to hide my code. You know the type who looks are your code and says in that condescending voice “Why did you do it THAT way?” My old manager called it “ugly baby syndrome.” You code is you baby and you want to protect it from being call ugly.
Great post; when I started at the company I work for I had to run a particular system (huge btw) with a few other people whilst programming on other projects; one by one the other people left which left being the only person to understand it.
I was asked to write a new system that would make it easy for other people to run; which boiled down to me writing my own brief, designing the system, writing the system, testing the system, implementing the system, writing the manual for and training people on the system.
This was not good, I would have preferred more people working on this project, after all it’s supposedly a company full of programmers but it was needed asap. If anything goes wrong with it I have to maintain it, amend it update it - it’s a pain in the arse. Bring on the light!
Don’t forget the flipside: When your peers allow and invite you in to see their work, you should actively review it in a helpful and respectful manner. No one is served when you act like an asshole.
