@fdgsdfg:
Must… resist… clicking… on… obvious… spam…
“What do you do when somebody shows up to an open source project with a gigantic new feature that took months to write?”
Reject it. At the very least, nobody should be coding huge, undiscussed features over several months.
This links in with the principle of “do one thing, really well”. If a huge new feature is ever added, it should be initiated by the core developers, not a general contributor, because most of the time it won’t be The Right Thing to do.
This is something that open source generally does really well, being more associated with the unix world than the windows’ philosophy of ‘a few programs doing masses of stuff’. In my experience, ‘going dark’, particularly in terms of adding a huge new feature, is far more problematic in the proprietary world than the open one.
“Isn’t it their anti-social traits that characterize great developers in the first place? i.e. their greater affinity with machines than with people…”
Not really, no. If you were designing machine to machine software, it might be, but most software’s man to machine. Also, at least some of the best developers I’ve ever met have been great with people.
Going dark is bad, and I strongly believe in code reviews and regular iterations. But man am I sick of hearing about “agile”. Many of the concepts contained in agile have been used for quite some time. Others take things too far such as peer programming-only environments. What makes me sick about agile is: the way people act like it’s so f’n special, and so original. It’s not.
I like to say the most important skills for a developer are communications and attention to detail. Verbal and written communication are both extremely important. It’s not a matter of being social. It’s a matter of being able to describe what you did, or what you are doing, and knowing when to speak up. Way too many developers aren’t able to do that.
From gunther: “But, I wonder if there is similarity to other “artistic” endeavours? Many painters and authors loathe discussing work in progress. There is a feeling that talking about a project before it’s fleshed out can ruin or displace the train of thought before it is fully formed.”
Programming is not art. It can be right or it can be wrong. There is no in between. If a group of people disagree on the function of a button, then the button is wrong. The button should describe exactly what it will do. There should be no confusion.
If people disagree on the meaning of the red berries on the bush behind the girl reading a book, that’s art. People don’t die if they don’t understand the red berries.
This is a topic near and dear to me right now. I was forced to go dark. I’m new to C# (.Net in general) and was given a large part of a new project to develop. The client kept changing requirements, which changed the data model so I kept having to rewrite my code.
I asked my “manager” to review my code often – I’d ask him at least once a week of not more, over the past 3 months. He said he did and it was fine.
I was unable to mock up test data (the DB is very large, uses some MS specific ASP.Net user management stuff that I don’t understand, so I was unable to just make a temp DB on my own system for testing.) I was not allowed to create records to test with will-nilly because another guy on our team was testing with some of the same tables, and his data “should have covered every use-case we have.”
The result of all this is that a programmer who doesn’t know .Net was forced to code lines that he was never even able to step through in a debugger.
When this went to testing, things blew up. Really badly. Well, no kidding! I got the code to compile, but was really unable to test a large portion of it. The client got pissed, called the owner of the company and told the owner to fire ME (I’m the most senior programmer, if the most junior in terms of .Net).
So, coding in the dark, for me, was a disaster. I’m now relegated to a different part of the project, and I believe that some people, if not all, have lost confidence in my over here. I’m depressed, dejected, and generally pissed off.
Now I go and sit with my “manager” for hours until he gives in and pulls down my code and looks at what I’ve done. I’ve also gotten him to finally configure my machine with all of the ASP.Net user management stuff so that I have my own database.
Since I finally got what I needed to do my job, my speed has increased, my understanding has increased exponentially, and the last thing I pushed out to the client worked 100% bug free (so far).
A much better experience.
The opposite of ‘going dark’ is coding by committee, which is anathema to creative people. Most coders who undertake such a project view themselves as a sort of Michelangelo, and may resent taking advice from those who do not share their vision.
However, even great programmers are willing to take advice from a limited subset of people who have gained their respect. However, even here, feedback needs to be carefully filtered. Nobody likes getting burned by committee, especially a remote one who won’t take you out for a beer to soften the blow.
I read this piece on the same day as Jason's piece over at 37Signals called "How not to apply for a job." ( <a href="http://www.37signals.com/svn/posts/1088-how-not-to-apply-for-a-job">http://www.37signals.com/svn/posts/1088-how-not-to-apply-for-a-job</a> ) In that article Jason mocks a job applicant who put a space in the company name. In this article developers are encouraged to show work in progress, to be open and transparent and share code they know to be buggy. In that article developers are told they will not be considered for a job if they have a single typo in their resume. Now I'm not disagreeing with either article, but if you only hire people who are perfectionists, they're not going to share their mistakes.
We used to call this “under the cover of darkness” or “army of one” style coding.
Whilst there is the danger of ‘going dark’, I think there is also merit in one researching their new idea/feature/fix properly before answering inevitable questions from the team. There’s nothing more painful than being presented with work whose author is unable to comment on questions relating to its structure, integration, future, alternatives etc. In these situations there’s a big danger of the whole team being forced to reason about your work for you which conflicts with separating workload.
Some trouble must come when there can be no right way, when to make something clearer for one is to make it more obscure for another. Not too common, I know, but can happen.
Many times the reason I don’t like sharing code is for the same reason I don’t like many forums/chat channels: people are dicks.
Whether it’s a small error or a huge one, a typing error or a casting error – it’s immediately like feeding time in the badger pen.
I live in the dark all the time. I work for a small company and am the only developer here. I often share my code with my boss, who rarely understands it (he is a very competent DBA, but has little development experience). Most of the time, I explain the logic, he gives a nod as to whether he agrees with the logic, gives suggestions, and life goes on.
I dread the day that I leave this place and am forced to work on a development team. Because my job eats up a lot of my time, I’m not able to do “practice” by participating in the open source community. In the meantime, I read as much as I can about accepted development processes and organization, and do my best to follow them. I also try to review my code from another person’s perspective (which I liken to the difficulty of an artist looking at his work with another person’s eyes) which sometimes works out.
I realize that I’m part of a dying breed. Like the old farts before me, I can work privately and (mostly) unguided for months and then magically release new software. Admittedly, I’m a little selfish about my code, but the solitude and the “artistry” of coding is why I wanted to do this in the first place.
I think there are different levels of going dark and they shouldn’t all be considered bad.
If I’m working on something that requires a certain amount creativity then I will usually go dark for long periods. This has absolutely nothing to do with any insecurity in my coding.
I am extremely likely to delete and re-engineer everything many times as ideas develop in my mind. These first iterations are quite simply completely wrong. However, they are invaluable to myself as they often provide inspiration that allows me to produce something that is heading in the right direction.
It is at this point that I can put my ideas out there and get some feedback. I will be clear enough in my mind to explain my reasons for doing things, and the paths I took getting there. The main thing to note here though is that whilst I may have gone dark, at no point would I emerge with anything “perfect” or “finished”.
So whilst I agree completely with this article I think there are times when developers need to be left to their “artistic” methods of producing some out of the box ideas.
Going dark should not be something that largely depends on the character of individuals. I think the “span of darkness” reflects the unit size of job. If the development system is done right (clear specification, good abstraction, good modularity, well defined interface etc.), the unit size of job will tend to be small. If the size of job is targeted to fit into ,say, one day, it’s going to be hard to go dark for more than a couple of days (taking into account the possibility of messing up).
Once again, you make a point that reminds me of something my mentor would have said (it’s been about 2 years since I’ve worked with him… but still he harped on this issue more than any other). His point was that he could deal / work with a developer who doesn’t know how to program something; but would NOT work with a developer who doesn’t know how to touch base at least every other day with the tech lead (him).
Must… resist… clicking… on… obvious… spam…
Jeff is sleeping in today …
@jc “I actually think Git might enable people to go dark…”
Not really. GIT requires trust and accountability, as in merging code into your code base from trusted sources in your own personal network. It demands a higher degree of accountability.
@N
That’s pretty much the way people are. Anonymity on the internet allows you to be a jack ass to anyone. It’s rare to find “constructive” criticism from people unless it’s in a “professional environment”… and even then it’s pretty rare…
In terms of quality and time to market I can’t think of reason for going dark but I do it routinely for for two (2) habitually compelling and selfish reasons:
- he who codes, rules. (ownership)
- some might implement your idea [faster/better] [“robbing” credit/kicking your ego]
Even for the most lazy amongst us, there is a desire for control, recognition and authority. Springing huge chunks of code on people gaurantees at least one of these three qualities will come to fruition if it is deemed useful (and mostly working).