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."
Depends on your goals (Score:5, Insightful)
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.
Re:No micro manages or quotes with NO TPS reports (Score:4, Insightful)
A good team is tops; materialism is irrelevant. (Score:4, Insightful)
Fair remuneration is pretty damn important too, but a bad office culture will only attract people who are looking to gain in the short term. There is a hedge fund that is notorious for this here in the East Coast; they pay their IT staff *wayyy* over market but have office politics that would put the US government to shame and an extremely socially stifling office culture that makes it tough to stay there longer than six months.
Good luck!
It might be different for different people, but... (Score:5, Insightful)
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.
Tips (Score:5, Insightful)
Smart People (Score:4, Insightful)
If your team only consists of the smartest people in the world who have the ability to work with others, then your team will respect each other. This reduces the unhealthy type of politics and allows everyone to just work together to create the best product ever.
Allow these people to utilize their intelligence, have ownership in the product, and be able to find meaning in their work. Everything else is just perks.
Re:No micro manages or quotes with NO TPS reports (Score:5, Insightful)
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.
Intellectual honesty (Score:5, Insightful)
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.
Re:I Can Tell You What NOT To Do... (Score:4, Insightful)
Seems like a given for ANY healthy business culture; pay your employees on time. No matter how cool or fun of geeky a culture is, they are your employees because they need (not just "want") to have money. Your primary obligation as an employer is to pay your employees.
Other than that a business culture, especially on a small team, is driven by the individuals. Just make sure people stay respectful of eachother and work as they should and everything else will flow from that.
Transparency, Flexibility, Openness, Speed (Score:5, Insightful)
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.
Re:Stay away from agile (Score:5, Insightful)
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!"
Agile is just the latest buzz word ... (Score:5, Insightful)
Experiment, keeps what works, discard what doesn't.
More old people (Score:5, Insightful)
More old people. If the oldest in your team is just 30, then there's surely a huge amout of experience and expertise and wisdom that you're simply missing.
Re:Tips (Score:5, Insightful)
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.
Deming (Score:5, Insightful)
You may find many of his ideas surprisingly applicable to software development.
Varies from person to person, not group to group (Score:5, Insightful)
Re:Stay away from agile (Score:5, Insightful)
you did agile wrong.
taking an agile bible, going to an agile development course and then following the bible like a slave is the opposite of what actual agile development was supposed to be(the thing that was broken into parts and put into thick books and courses to sell to bosses to fleece them out of money).
you can spend all the time on the process no matter what process you choose. it's just that there's shitloads of people fleecing money from people who have money and agile happens to be their buzzword for last year, then they sell them friggin software to take care of the agile process. what has happened in many companies is that they've just plastered "agile" on top of "waterfall" and relabeled the sw they used for waterfall, relabeled deadlines as sprints etc(while retaining that specs change in a waterfall fashion, too. that's pretty fucked up, supposed to be working in agile methods but guys who make design decisions about what the sw should do give input through 3 line emails every 4 weeks - so what these companies are(some were, with now shutdown offices) doing is just agiling one _step_ of a fucked up pisswaterfall, that is not agile at all it's just making everybodys life a weekly micro managed waste of time).
sounds like your iterative spiral waterfall is more what actual agile should be than what you had implemented, in other words, just figuring out what needs to be done and then doing it.
it doesn't have anything to do with this ask slashdot subject though, except that you can't buy atmosphere from a brochure(or from a slashdot thread), it's up to the guys in the office to be cool or not... I'd advice to stop looking for how to be cool guides from the internet. bring a ping pong table, nes, fussball, beer.. *whatever* to the office - and try to get aware what your employees would consider to be living the dream, for example I had fun times going to some developer conferences and getting wasted, but since I had to drop booze - and because I've already seen what 3gsm was like - I'd consider some different perks as nice.
oh and pay your developers on time, be HONEST about the state of your company - if times are bad just tell them that, when it's going well tell them that. don't save money on things that make no sense to save money on, that is buy them the tools they need, don't give them joke computers to work on because "php editor works just fine on that". encourage them to stay up to date on industry buzz, so that they can call bullshit when they see it.
Re:Good Development Culture (Score:4, Insightful)
Watch out for intelligent developers whose strongest skill is creating the appearance of working without actually doing any. Watch out for intelligent developers whose main skill is undermining the work of other, even more intelligent developers. Sad but true, there is a subculture of both kinds of developers circulating through the industry moving from company to company just ahead of their termination notices, relying on the fact that no former employer will take the legal risk of telling the truth about how they actually performed.
Re:I Can Tell You What NOT To Do... (Score:5, Insightful)
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.
Re:culture? (Score:5, Insightful)
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)
Re:No micro manages or quotes with NO TPS reports (Score:5, Insightful)
No standing up! First that gets really close to agism. Some people say only 5 minutes max but it won't happen, some doofus will keep talking. Standing up as a goal to keep meetings short will not work, it will just make people feel uncomfortable and fidgety. The only reason to have one is if your company is too poor to buy chairs and the carpet is too dirty to sit on.
If you excuse yourself when you no longer feel useful, no meeting would ever last more than 30 seconds.
Adopt good developer tools, process (Score:5, Insightful)
Good developer tools make all the difference. They get the hell out of the way of doing work.
(1) The biggest thing you can do to make people happy is fast builds. That generally means rolling your own, since tools like emerge/ebuilds and so on all have horrendous overhead. A null build of a product containing 500 modules (for example, an embedded Linux device) should take no more than 10 seconds. If it takes more than 10 seconds to do nothing, then you are doing it wrong.
(2) The next biggest thing you can do is proper build. Building is half the battle; the big thing that stops work is integration failure. Say you have 500 packages in a product, and you make a change to one of the packages; what should get rebuilt? The answer should be (A) the package itself, and (B) whatever depends on APIs exported by the package. Yes, this means properly expressing dependencies. This is hard. Boo hoo: you are getting paid because you do hard things that you ordinarily wouldn't do, except if you were getting paid. Get the hell over it. Doing things this way is incredibly important in order to resolve #1: If I can use binary build products for all the packages I'm not working on, obtained from a previous build, then all I have to concentrate on building is the things I'm currently working on. A 30 minute build goes down to a few seconds.
(3) This is necessary to resolving the build: Have strong inter-module contracts. A package that exports an ABI used by one or more other packages should damn well export a linkable library and header files. If the library version doesn't change, and the header files haven't changed, you don't need to rebuild the damn thing. But this can only be properly known if you have partitioned your packages such that they export ABIs. The ABIs should be documented, and these documents are contracts, where you agree not to break the contract from either end of things. A dependent package needs a new API? That's a negotiation. A Package wants to deprecate an API it exports? That's a negotiation, too.
(4) After build works, you need integration. Integration boils down to using branch tags in your source code control system. This is necessary when someone attempts to submit a change that breaks things: instead of being dead in the water until the change is fixed or reverted within the package, and waiting hours, the B&I team reverts the package version to the previous version, and you are good to go: Things take minutes, not hours, days, or weeks to resolve. The B&I team is God, but their deliverable is binary packages. This is important in support of #1.
(5) React appropriately when things go wrong. For example, if someone commits a test that's broken, but the test isn't exercised, and three weeks later the code path gets activated by a change and breaks things, do the right thing. The right thing is to back the hell out the change that activated the code path. The wrong thing is to try to fix the test at that point, while everything stays broken on the theory "Ah, this is a smiple fix, I'll just fix the test instead". You may look like a hero for fixing the test after a couple days or a week, but you aren't, you're the bottleneck who killed the productivity of the rest of the team while you were trying to fix the test. Bottom line: back out the proximal cause of the problem, and fix the root/distal problem out of band. Everyone gets to get more work done.
(6) Test appropriately. This is almost never done; most testing is reactive. What I mean by this is that people tend to write tests to verify that things are fixed, and then integrate those tests into their waterfall; that's a reactive test. This is almost never useful, since it doesn't verify correct behaviour, it only protects against regressions on a bug that was noteworthy enough that it's unlikely to repeat. Instead, testing should test desired product functionality. One aspect of agile programming that is a good idea is writing the functional tests before writing the code.
Hire some older, and smart no-BS people. (Score:4, Insightful)
*) Don't turn your workplace into a fraternity.
*) a super-automatic espresso machine, and pay for all the coffee & maintenance of said machine.
*) Agree that you don't want to do anything stupid or wasteful even if some book, or person, think's its the 'best practice' or 'cool'
*) newer is not always better. Newer is not always worse.
Good Boss, No End-User Support (Score:5, Insightful)
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
Re:No micro manages or quotes with NO TPS reports (Score:4, Insightful)
If your boss can't leave you alone and let you work, then you have more serious problems than too many meetings.
Re:culture? (Score:5, Insightful)
This.
Want some incredible results from your software engineers? Here's all the culture you need :
Give them a very quiet place to work, free from distractions, and take away the barriers to success / productivity.
- Too warm? That's a distraction that will destroy any attempts at getting work done that day.
- One or more people having personal discussions loud enough that the dev overhears them? Esp if the chatty people aren't on the dev team? Another day's productivity pissed away.
- It takes a good developer half an hour or so to 'get in the zone' doing heavy / hardcore coding and debugging. If he has to get up and go find food all those balls in the air drop to the ground and he starts over again when he finally gets back from eating. Find out what they eat and have it magically show up at their desk about 11:45am and they will feed their face while they continue being productive. If they're billable that extra hour, then there is nothing on Earth that you could feed them that costs more than that billable hour (but odds are they will be happy with a subway sandwich and a bag of chips.)
- Need to request permission / wait for a signature before doing something routine? Need to wait to have someone else make changes that the developer could make (perfect example : DDL or DML changes in the developer database)? Another day's productivity lost.
- Figure out who the slackers are and cull the herd a little. A small team of shit-hot developers that work well together can deliver rings around a larger team mixed with good / weak players.
- Any meetings that are useless? Don't make them attend. Any meeting with 8+ non-developers in it is probably useless, from the 'does a developer need to be here' perspective.
- Give the heavy hitters more hardware than you can imagine them possibly using - they'll find a way to put four monitors, two servers and two laptops to good use, and anything they don't use they will pass on to someone that can. Nothing says 'I love you' to a good developer than a new tech toy, or a new laptop when their old one is about two years old.
All that 'team-building' crap? Save it. Want a real team-building exercise, send a few of them away to a conference and only give them one car so they have to stick together, give them enough rope to get in trouble together. When they come back they will be an Olympic quality team.