7 ms·
Wow. I guess I'm completely different from Jeff. I have no need whatsoever for a "coding buddy." I'm considerably more comfortable working on a project solo. E
by lukev 17y ago
Wow. I guess I'm completely different from Jeff.
I have no need whatsoever for a "coding buddy." I'm considerably more comfortable working on a project solo. Even with a good team, I hate the coordination overhead.
I can, of course, and good team skills are important. I'm not saying that. But the coordination costs of software development increase super-linearly, so I tend to prefer using the minimum number of people that can possibly do a job. The break-even point is around 4-5 - after that, adding more people makes things slower, unless you can split the project into autonomous chunks.
- acro 17y agoAnd it sometimes seems very difficult to explain to the management types that adding people to the project will not make it go any faster.
- lukev 17y agoOh, no... they don't add people. They add "resources."
- hello_moto 17y agoSaw this in a software as well recently. There was a grid/table for adding/removing employees. But the title said "Resources".
- gaius 17y agoYet they sure don't like being referred to as "Powerpoint resources".
- MartinCron 17y agoEven though it was 15 years ago, I still vividly remember the disquiet I felt the first time I heard the term "human resources". It felt so Soylent Green to me. Even though he's not universally popular around here, I'm going to admit to liking Seth Godin's "Let's call it the talent department" argument: http://sethgodin.typepad.com/seths_blog/2008/02/marketing-hr.html http://sethgodin.typepad.com/seths_blog/2008/02/marketing-hr...
- gvb 17y ago...and most of the time the "resources" are aggregated into "full time equivalents." :-(
- eavc 17y agoVespene gas.
- run4yourlives 17y agoJust give them a link: http://en.wikipedia.org/wiki/Brooks_law http://en.wikipedia.org/wiki/Brooks_law
- Legion 17y agoOne too many s's. http://en.wikipedia.org/wiki/Brooks_law http://en.wikipedia.org/wiki/Brooks_law
- run4yourlives 17y agoWeird, I cut and pasted that link. Oh well, edited, thanks.
- barredo 17y agoMy order of preference: Working with better programmers than me > Working solo > Working with others I guess it is a common preference
- ewanmcteagle 17y agoIt is. I agree with you but if you're working with programmers better than you which one of these three is the situation from their perspective? At least some of the better programmers have to be willing to bend on this or you never work with anyone better.
- digitallogic 17y agoYou only need to perceive that the other programmers are better, they don't actually need to be that way. And given that competent people generally underrate their abilities [1], you could have a team of equally highly skilled people who all think they are working with a team that is generally better than them. I actually think this would be an ideal situation. 1: http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
- fnid2 17y agoThey don't have to be better. What is "better" anyway? More efficient algorithms? More normalized data? Fewer bugs? For me, it's about experiences and perspectives. When I work with other programmers who have unique approaches to problems that help me work more efficiently, I enjoy working with them. I also enjoy working with less experienced programmers who are willing to learn and practice new, more efficient methods. I really dislike working with programmers who think they are awesome, but are really clueless. I try to help them, but their pride gets in the way. It's funny when they try to school me on stuff. I just don't have time for that. I feel bad for their clients. But sometimes I run across people who know little tricks or constructs and I'm like, Wow, that's awesome, teach me more!
- digitallogic 17y ago
- brown9-2 17y agoJust curious: have you historically in your career worked mostly alone/remote, or in offices? Or somewhere in between?
- lukev 17y agoMostly in offices. I like it ok - ironically, it tends to reduce overhead because I can swivel my chair to ask a question rather than waiting for an email or IM response. We all have headphones that we wear as a "do not disturb" signal. I feel most productive on days when I can dive in and wear my headphones for most of the day. I think I'd like working by myself if given the chance, but I've always worked for fairly traditional companies.
- csomar 17y agoBut you won't go so far alone! You can't code the whole StackExchange engine solo. You need a buddy (may be buddies). He/they should be smart, love code (love his/their work). It doesn't matter if he's not working in the same office as you, so you telecommute. That's what Jeff explains in his blog post.
- lukev 17y agoAdding more people to a team because the team has more responsibilities than one person can handle is one thing. Needing "coding buddies" because you're lonely (which is what Jeff made it sound like) is another. I can of course work on a team when the project is beyond the scope of a single developer. I prefer to work alone, since that entails exactly zero coordination overhead.
- 83457 17y agoI think it may come down to the complexity of a project. For something non-trivial simply having someone to bounce ideas off of can make a big difference in one's overall efficiency, and thus probably happiness.
- fnid2 17y agoI agree, but I will also say that you can almost always find ways to get more done with more people. For example, it's easy to break up a project into code, css, html, javascript. That's four people right there. You could also have a graphics person drawing icons or cool backgrounds. You could have a database person. At some point you'll need a networking guru, marketer... It's easy to get into the trap of thinking it's all about code, but there are lots of ways to add people. Sometimes, coders don't want to add people, because it's one more person asking them to code something. Coders often don't know how to push back and say, "This is what I'm working on, this is what I need you to do." Every answer to an IT problem is "It Depends." In this case, the question of "Does adding more people make the project go faster or better?" is "It depends." This question can't be answered with a general absolute.
- DougWebb 17y ago
- BrandonM 17y agoI agree with your sentiment, but I think it could be helpful for me to have a "coding buddy" to share things with, someone who is not involved in my project. It would be kind of nice to have someone to share particularly clever code snippets with, or to help motivate each other by being able to proudly relate the process you're making in development. At first I thought that's what Jeff was going to talk about. As far as the actual programming, yes, I'd prefer to do it alone. I love being able to make major decisions (think: changing an internal API) without having to consult with someone.
- harisenbon 17y agoI would love a coding buddy. At my current work, I am the only programmer in an office of designers and sales. We (I) make CMS and other custom systems for clients. We really want to move to a generalized platform instead of one-off custom systems, but due to a number of issues, we can't. One of those main issues is that there is no one like a programming buddy to "talk shop" with. I feel I am an OK coder, but everyone gets those times when they think "Should I implement this with A, or use B? Does this need to be extensible, and if so, to what degree?" These are questions that usually cannot be answered by someone who is not deeply involved in the project, and someone who knows what the resource costs are for implementing features, as well as the cost for needing to implement those features down the line.
- abhirakshit 17y agoAgreed , having a buddy really helps get things in perspective. Moreover, I work in a startup where direction of things get changed really fast. Not sure having remote people in this type of scenario will work.