Ask Slashdot: What Defines Good Developer Culture? 239
An anonymous reader writes "I'm part of a team of six people developing applications for mobile devices (Android & iOS). In our company, which consists of many teams responsible for 'classic' software development, business intelligence, virtualization, hardware, etc., we are kind of a small startup because we were the first to use agile methods like Scrum and we are open to new technologies and methods. Also, our team is pretty young — I'm the oldest at 30 years of age. We would like to further raise productivity and motivation, so we're currently collecting ideas about what makes a good developer/hacker culture, and how it can be improved in our team/company. These can be things we do ourselves, or suggestions we pass on to management. I would like to know: what, in your opinion, defines good, modern developer culture? What does developer culture consists of? For example, is it: clearly defined career opportunities? A geeky office? Benefits like trips to extraordinary conferences? Please let me know what you think."
Re:Good Development Culture (Score:5, Informative)
This truly belongs in the category of questions that if you have to ask, then you're not going to understand the answers...Mostly because they will be of the same caliber as the question.
Joel (Score:2, Informative)
http://www.joelonsoftware.com/ [joelonsoftware.com]
Beware the Agile/Scrum Zealots (Score:5, Informative)
and adapt the methods to suit your envinorment.
Don't stick to the letter of their methods, stick to the principles.
Don't be afraid to admit that you are wrong and change track.
Be honest and cut the bullshit.
Have fun and take the team out for some beer (or whatever).
When trying agile, use retrospectives (Score:4, Informative)
I think it's important to have structured feedback moments, and one of the most important and central tools I found to agile development (but it probably applies to all development) is using retrospectives (retros). In the company I work at, we do them after each code sprint, every two weeks.
In a good retro, you find about what is hurting your ability to work and define actions against those blocks. An easy to run retro which usually yields some useful results is the Mad/Sad/Glad retro:
Create a big area with three columns: what makes you mad, what makes you sad, what makes you glad. This can be on a big sheet of paper, a whiteboard, virtually (like Google Docs), ... Every team member creates as many small notes as they want and put them on the right column. This is more useful if everyone has to think for themselves and is not influenced by others (eg: create post-its on yourself, then hang them in the right column), and/or if it's done anonymously (eg via some software tool). When everyone posted his/her things, every team member casts votes on what they want to discuss. You discuss the most voted-on items, and try to formulate one action for each to improve on it. You typically want SMART actions: Specific, Measurable, Attainable, Relevant, Time-bound - aka well-defined with a clear goal.
Retros should be time-boxed, there should be a neutral "facilitator", everyone should be able to participate, no-one should have to hold back his opinion. A few people who try to discuss for the sake of discussion can be a good thing if it's not overdone: try to use every technique to get people talking and spouting the unhappiness, acknowledge it, and fix it.
In the last few months, we've splitted our team, installed new tools, decided to start reading groups, and brought more candy, all out of retros.
Avoid UML, unit testing, instant messaging, Git... (Score:2, Informative)
Avoid UML, unit testing, instant messaging, pair programming, and Git. Total wastes of time!
Fans of these fads will think this comment is a joke. But I'm serious. I've worked on a lot of projects, and every one of them was dragged down by one or more of the things I mentioned.
Actually, unit testing is acceptable, but only in extreme moderation. The risk of going too far with it is so overwhelming, though, that I think the best recommendation is to avoid it, until you get really clear about the risk (time invested) versus reward (bugs reduced). If developers take more than 5% of their time developing tests, you've failed. If tests need to be frequently re-written to accommodate changes to various APIs, you're wasting more time.
If the team is productive, then don't eagerly seek and adopt new policies, procedures, or technologies to try to gain some hypothetical 10% productivity improvement!
Also, your goal should be to manage things well enough to keep coworkers in the office for under 8 hours every single day. If you feel compelled to keep people in the office longer than 8 hours on any given day, you've failed. If someone has to come in on a weekend, then it is an epic fail. You should be really clear about these things. The mark of a failing project is overtime and weekend time.
Culture HOW-TO (Score:2, Informative)
Read this:
http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf
And This:
http://www.nczonline.net/blog/2012/06/12/the-care-and-feeding-of-software-engineers-or-why-engineers-are-grumpy/
Watch This:
http://www.livestream.com/etsy/video?clipId=pla_780bfe22-12e8-4c7f-8c7b-06cc6cac9c49
That should get you started.
Re:No micro manages or quotes with NO TPS reports (Score:4, Informative)
Only stuff from category A should be send via e-mail. Everything in B and C you throw on a wiki, bug tracker, reference docs, etc so they can look it up themselves when they need it (instead of when you decide to send it). The only exception is a quick 1 line e-mail saying "the informatin regarding FOO you have been waiting for is now available at BAR" with a link to the resource.
Not only does this keep the e-mail volume low (and increase the chances that your employees get the information they need), it will also help centralise and enforce your documentation instead of fracturing it among 10 employee inboxes.
A CS/CIS/etc degree is not required (Score:4, Informative)
I never got a degree, mostly due to ending up studying the wrong area (electronics) and eventually falling out and not getting a degree. I'm quite curious to the actual worth of the degree, if all you're interested in inherent interests. I have a job as a software developer, so it isn't a personal question, just curious. I imagine there are also people who end up getting a non-CS degree, but have an inherent interest in software development.
A CS/CIS/etc degree is not required. It is quite plausible to study all the topics covered in a degree program on your own. The problem is that very few people who embark on that self-taught path will study all the necessary topics. It is too tempting to cherry pick the interesting topics and pass on the less interesting. The problem is that some of the less interesting topics can be quite important. "Less interesting" varies from person to person.
A formal degree program has the advantage that a person will be coerced into study all the relevant topics, "interesting" or not. Most people can benefit from that sort of formality. Add to all of this that one can get access to some pretty cool hardware at a university that one would not get access to otherwise. Plus there is the environment of being surrounded by others of similar interest and abilities. What you and your fellow students learn from each other complements what you get out of class. Some professors, but not all, can also teach valuable lessons not normally covered in class.
I have worked with some great programmer who never got a degree. I would be happy to work with many of them again. However they probably could have been even better with the formal training. Self study, practical experience and formal training are all good things. Each complementing the other and taking a person a little bit farther.
As for inherent interest, that is something entirely different from training or experience. IMHO a person who lacks an inherent interest in software development is unlikely to become one of the better developers.