Slashdot Mirror
Ask Slashdot: What Defines Good Developer Culture?
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."
I've seen many different developer cultures. Keep in mind people are not clones. What works for one set of people may not work for another. In an attempt to be trendy and hip, some groups seriously backfired. Ultimately, get to know your team and adopt whatever works for keeping your team productive, happy and constantly improving. This will vary from team to team. There is no substitute for getting to know your team and practicing decent project management.
For me its flexibility in the hours I work, access to training, and being able to write the kind of code that I think should be written for a project.
By flexibility to don't mean full time or part time, I mean that I can come and go as a please as long as I meet my project requirements and make my time.
Training includes classes, conferences, research projects, and access to research materials such as books and hardware.
I've worked for a couple of companies where I was just a code monkey who was only allowed to fill in the blanks that my betters left undone. That kind of job is a nightmare of poor design and implementation.
10: PRINT "Everything old is new again."
20: GOTO 10
There are productive meetings and there are not so productive meetings. A lot of effective management is shielding your people from the unproductive ones and getting the right people to the others when needed. At 6 people that's pretty easy to do.
No sir I dont like it.
I think the single most important attribute for any technical person, and thus for the culture, is intellectual honesty. This includes things such as:
Admitting candidly when you do not know something
Actually listening to other people's ideas and opinions
Giving credit freely
And a friendly, rage-free culture doesn't hurt, either.
expandfairuse.org
Transparency: Don't hide business motivations or other important business information from your employees. They may have valuable input to share.
Flexibility: If you're primarily a software company, being flexible with your employees costs you little. Allowing them to work at home occasionally helps, and if you're flexible with them, they're likely to be more flexible with you when you need additional hours to get something out.
Openness: Hire good, intelligent generalists, and let them come up with the best solutions. Don't micromanage; hire people you won't need to micromanage. Further, let your team, especially the developers, use whatever solutions they think are best. Operating system, editor, hardware, whatever. Obviously for your actual product you'll need consensus, but anything specific to one developer should be up to them as much as reasonably possible.
Speed: Resist just about everything that increases the time it will take for you to come up with a working solution. As a startup, speed is your biggest asset compared to bigger software companies. Keep it as long as you can. (This doesn't mean that you should avoid planning at the beginning of a project, just that you should keep your business systems free of red tape as much as you can.)
I hear recruiters talk about companies with "awesome cultures" and how they have "Xboxes in the office" and all sorts of "perk" things like that. Those are great, but it's not the reason I'll want to work somewhere, because in the long run they mean very little.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
I've worked for three companies that did it, and we wasted more time with process than we spent getting actual work done. Instead, study the waterfall method and learn the good parts and bad parts from it. Then implement waterfall in a iterative process. Some people call that the spiral method. You'll have good disciplined iterations rather than intentional half-ass sprints like you have with agile.
Here's another perspective from a 50 year old programmer who has worked with a number of teams and has code on millions of PCs. Stay away from all labelled "methods" of software development. When project managers and programmers start spending their time thinking about and talking about Scrum and Agile and Waterfall and Cowboy and so on and so forth, they are moving farther and farther away from developing software in the most efficient way for the team that's doing it. Don't be afraid to make incremental changes to how the group is already working to improve things, but don't make the mistake of one day announcing "Okay! Let's all start using {insert labelled fad here} and get really productive!"
Some tips I'd add, as somebody on both sides of this problem:
5) Money counts. If you pay for quality as well as demanding quality, you'll get it. If you give people profit sharing, they'll try to create more profit.
6) Give your techies the same opportunities for bonuses, advancement, and prestige as other kinds of employees. If your company lavishes money and praise on its sales team and ignores the techies who've labored night and day to build the product that sales team sells, they'll grow resentful at best.
7) Give your techies opportunities to advance themselves in their profession. Send them to conferences, give them time to put into professional organizations relevant to their role, etc.
8) Make absolutely certain you keep on-call duties reasonable. If you have off-shore tech teams, take advantage of the time difference so that somebody can handle emergencies at all times without being up at 3 AM (e.g. have admins in the US responsible for 7 AM to 7 PM EST, and admins in India responsible for the other 12 hours which is roughly daytime there). At the very least, you should rotate front-line on-call duties among as large a group of people as you possibly can - 2 weeks of on-call is annoying but manageable, 1 week out of 3 or 24/7 is seriously painful.
9) Build cross-functional teams. Your techies should not be isolated in a corner, they should be interacting regularly with their users (for internal tools) or their sales and customer service teams (for products sold to the outside) so that they gain some direct knowledge of the effects of their work, and so the other teams don't think of the techies as a bunch of gnomes in a cave that come out with more bugs periodically.
10) When you ask extraordinary effort from your team, be there with them. For instance, if you expect your team to be in at 3 AM for a product launch, get there at 2:30 with coffee and whatever snacks they like. Even if you aren't actually adding much value, it definitely improves morale.
I am officially gone from
Uh, what? I've worked at a number of jobs, and in 16 years have never once been paid late. That's like, big red letters "GET THE FUCK OUT" warning sign right there. Your employees will immediately start looking for other work.
Pay your building lease late. Pay your electric bill late. You won't get kicked out, and the lights won't get shut off, for not having the money for two weeks. Chances are, your employees will never know, and if they do, they'll accept pretty much any BS excuse you can throw out there, including, "heh, I forgot to pay the electric bill."
But they'll never, ever, ever, ever forget, or forgive, when somebody doesn't pay them. If you're any different, you should be aware that you've got a pretty bad case of battered-housewife syndrome.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
I know this is a joke, but seriously what the hell is "developer culture"? There seems to have been this bizarre and nonsensical fad with HR groups about developing corporate culture recently. They'll talk about what their culture is and try to foster it and all sorts of feel good fuzzy things, without even acknowledging that every building and every part of the buildings will have teams that act differently. The only times "culture" seems to make sense is with describing dysfunctional companies where some people don't fit in with the in-crowd and are excluded. I've seen kids complain that the companies they've applied to don't have a good "culture" and whine that they're expected to do unreasonable things like show up on time and get the job done.
Only culture I've ever really seen in real life is that building A has the group that goes out and gets wasted every thursday, building B has Hawaiian shirt fridays, building C has the IT guys who stick to themselves.
You definititely do NOT want homogeneous culture. If you have a goofy guy with all the toys you do not want that in every single cube. You don't want the guy with the tie in every single cube. You don't want everyone to be the same age, race, or gender. You don't want developer culture to be hippie dippie stuff like everyone has to sit around and brainstorm for 2 hours on tuesday, or have stand up meetings, or to give daily reports. You just want people who can do their jobs and interact with others. (I'd suggest not doing agile either but I see the OP has drunk that koolaid already)
Have a good boss. Really. He doesn't have to be the nice guy everybody loves. That probably won't help. His real job is to keep the management's political games away from the developers, and to translate between nerds and managers. Most times, your ideal boss will seem just to do some paper work, and not mess with nerds' stuff. From time to time, he will ask how far the project has progressed, and occasionally, he will tell you that the stuff really has do be done before a certain deadline, at least so far that the stuff does not crash within the first five minutes. And when things are really burning, he's the one that listens to you when you need someone to yell at.
That was my first boss, and I still miss his talents. My current boss is a moron. No clue of management and politics in management, no clue of project management, hardly a clue of software development, but he knows his computer well enough to find mouse, keyboard and power button. Unfortunately, this makes him think he could manage and administrate computers. And, my absolute favorite, his completely irrational optimism. If he would drive at 200 mph against a solid wall, his last words would be "I'm perfectly optimistic that I will survive the crash without a single scratch".
The most important thing: Keep end-user support away from developers. Nothing kills concentration more than a phone that rings every few minutes, with a completely clueless user on the other end of the line, telling you that his "computer does not work, and it's all your fault".
And, you may have already guessed that: My current boss forces me to support end-users, during development.
Tux2000
Denken hilft.