You know this isn’t cut and dry. Great software rarely comes from a committee. Because without fail there’s going to be one or two(or more from my experience) a-holes that are going to come up with some incredibly stupid and illogical suggestions that management is going to agree with and you end up with incredibly craptacular projects that you were forced to be a part of.
Sometimes a really good dev has to roll up his sleeves and grab the bull by the horns.
Plus, when it comes to an application, in my experience hardly anyone ever really knows what they want until you give it to them.
You know, there are times when the chef just needs to tell all the kids to get their grimy hands out of the soup pot so he can concentrate on making something decent he can serve to the patrons.
@Craig Smith: I really cannot comprehend the outrage over companies throwing out resumes over stupid, easily avoidable mistakes… I mean, when you get so many applications, you need to weed them down somehow.
gunther wonders if software development is akin to artistic undertakings. Kenneth uses a cooking metaphor with respect to programming. However, we can clearly see that programming is not any of those.
Yes, creativity is very much part of discovering solutions and may be part of coding as well, but we could not compare the creativity (thought process) that goes into painting, writing (literary works), or even cooking to programming.
Programming is more like manipulate raw materials at the physical level as opposed to cooking or painting where thing are changed at the atomic level and so the final/finished project is a completely different beast. While programming, a programmer acts more like a carpenter --a cabinet maker. Every piece of the project makes sense independently of the rest of it and so is subject to being viewed and reviewed.
In the case of a cook or a painter, one could not say this.
Besides, lets not forget, we do associate programming with sciences and not the arts. It is perfectly reasonable to ask a scientist to repeat his/her work. How absurd it would be to ask a painter to re-paint one his/her paintings. Or, to ask a cook (a real cook not the dude who puts pieces of pre-cooked canniloni on the plate at the Olive Garden) to repeat himself.
Finally, the final works of art have to carry a bit of magic in them ( some mystical factor has to be at work). That is partially why, the same bowl of pasta does not taste the same to me as it does to you. We interpret works of art differently at different times. While with programming, a set of statements are a set of statements are set of statements.
Oh, really? The title of the post is “Don’t Go Dark,” and the theme is that programming large blocks of code by yourself is a bad practice. Just read the last paragraph. Doesn’t seem like I’m putting words in anyone’s mouth.
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!)
Actually, he already did:
I do read every comment that is posted here, and although I am unable to respond to them all – I can barely get through my email backlog these days – rest assured that I eventually read every single individual comment left on this site.
Also, check out ‘Here Comes Everybody’. In this book, Clay Shirky notes that for all that the Internet does to facilitate two way and group discussions, it still cannot solve the ‘fame’ problem.
@adam: I think you may be overreacting a little. I didn’t get the impression Kenneth thought Jeff assumed that, I didn’t get the impression his comment was directed at anyone in particular. One of the things I like about this blog is how civil and professional the people are. Forum comments don’t allow for the nuance of face to face communication so it’s easy misinterpret someone’s intent. In fact it’s possible I just did that with you, and I apologize if I did.
I personally don’t agree with his comment, but that’s because I feel that feedback plays a vital role in getting my projects right.
“Remember a few years back when Linux released their daily build and the ports/socket code snagged credit card info and dished it out to a Russian server? Not a single “code reviewer” found it but after over a 1000 installs people started wondering what all that traffic was in their log files. If you can post a link to this story I think it would be great. Google seems to have been able to completely remove it from their index.”
The simple reason you can’t find a reference to it is that it did not happen! If it had Microsoft et al would have had a field day and would have splashed it across the world’s press …
The problem is that when you tell people what you are planning to do, there is always some a**hole who knows less than you who is going to criticize your plan. It takes a brave developer to continue with their original plan after getting flamed in public.
Wow, I have to reply to mushroom’s comment. The whole point in “questioning” the “plan” is the entire POINT of teamwork. If you think that a subordinate who knows “Less” than you who asks questions is an ass**** you encompass this entire thread.
Here is my definition of a TEAM per this article which goes against that very mind set from Mushroom which is just one example of many attitudes out there from the Dark Side which makes IT a crappy place to work in probably 75% of the work culture out there:
You may be an alpha programmer, a Sr. Developer, Lead etc. However, as a professional, it’s your duty to help the guys who are still trying to learn and become a better programmer. If you have fellas on the team who are mid-level or Jr’s, you should be more than happy to answer questions as long as those developers have made a decent effort to look things up before asking them. Or…you may be in a meeting, and questions just come up. While there is a fine line betweeen YOUR time and the rest of the team and YOUR project…if you are a player on the team, you should try to answer those even “dumb” questions. Granted there are sometimes you may say you do not have time and that’s perfectly fine, but do not be a prick about it, and come back to that developer later to see if they are still struggling. At a Sr. level, I feel it’s a given responsibility for the better of TEAM.
Not sharing the “why” or “intent” on your plan to the rest of the team is bad communication. If you’re adding lets say a new validation framework, and you’ve just checked in code to Subversion or whatever source control you are using, you should at the least not only tell what code you’ve changed, but why if it affects the rest of the team on things such as new patterns, new frameworks, or even simple intents. Those things should not be hidden from the team, because you’re just wasting other people’s time since they will just come back to you later to ask you “why”. Why not say it up front to save yourself TIME.
Tone. Whether you have a bad day, your wife just beat you upside the head with a bat this morning, your kid threw up on you, whatever…do not take it out on team with your tone. If someone asks you a question and you’re busy, politely tell them. Don’t sit there with an atittude and a free ticket saying “I can be this way because I had a bad day”. NOT professional and I expect people to expect the same from me if I am part of TEAM.
Just because things are inferred to you, doesn’t give you the right to assume they are inferred to all. So just chill… if a developer is asking you for a more “detailed” answer.
that’s just part of TEAM…and I think more developers need to change their attitudes in how they react, engage, and work with other developers as a whole both at work and outside of work.
Everything is great but you always have to think about time spent. And instead of reviewing any open source or commercial code it is more profitable to write your own.
Programmers share this trait with mathematicians, there’s in inherent desire to spring your beautiful diamond on your peers as if it sprung from you mind perfectly formed.
How many academic papers include all the dead ends and mistakes made on the way to the final solution? Very few I believe.
Not everyone enjoys collaboration, or more accurately they probably would if they can find someone of the same mind, which is rare. Going dark is likely a reaction to them not trusting the other team members enough to let them into their process. Going dark isn’t the problem, it’s merely a symptom.
@Fred writes,“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.”
Ah, that would be the “Retrieve a Recordset From the XYZ Database, Filtering on the Specified Search Criteria Entered by You the User” button. It’s got a nice ring to it, kinda catchy.
