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."
An emphasis on keeping high-quality & intelligent developers. Don't ever let intellectually lazy developers onto your team.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
I now work in a very great job at a university, but prior to, I worked as a social media developer at __unnamed company__. While my background was in programming using C++ and derivatives, I also knew php and Javascript so it wasn't a stretch to start working there, building Facebook apps and such.
They got me on board for a somewhat decent (out of college) hourly rate and gave me 250,000 shares of stock to sweeten the deal. Working remotely, I'd do 2-3 weeks onsite at the home office, and 2-3 weeks off, during the off times going back home - I got more done when I was at home, truth be told. I'd have to be up all hours of the day, sometimes getting 3-4 hours of sleep in between being called to fix some mistake someone made.
I ended up having to wait 2-4 weeks for my paychecks sometimes, all the while the boss was wining and dining people, and flying all over the place. I let it slide, and eventually got a bonus system added to my pay for completed work.
The 4th time I was to be paid a bonus (for taking over the role as sysadmin on top of everything else, as the previous guy left), I got paid but then they put a new guy over me, who got salaried making 3-4 times what I was, who used a completely different language than any of the other developers in the company. Three weeks later my boss breached my contract. I'm contemplating litigation.
From my experience there, you should most definitely always pay your employees first, and treat them with respect. Furthermore, going geeky and loose on schedules and such is fine, but you should require 40 hours a week from everyone, regardless of when or where they get the work done. Incentives are nice, but don't make them too good. Further, treat everyone equally in terms of praise and respect...Finally, make sure not to allow drama in the office, it only destroys companies from the inside out.
As an added bonus, you should make sure and not allow drinking and drug use in the work place. My former employer did, and there were a lot of useless sponges that just sat around drunk/high all the time.
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.
You know, the kind of "methodologies" that managers use to feel important and sophisticated.
http://programming-motherfucker.com/
As a consultant I've working in dozens of offices around the world and seen it all. The top factor is people. The best offices were those staffed with people who have the ability + desire + motivation to complete the work. Even just a few sub-par or bad attitude people in any role (managers, customers, testers, analysts) spoil it for everyone else. Have people write code during interviews, hire people on 1-6 month trial contracts before hiring permanently.
Next is managers who frequently inspect the work being done. If a manager isn't technically capable or doesn't regularly inspect work products in detail, then he/she isn't really managing, they are just hoping. Status meetings are not good enough if all that happens is the "manager" asking people to evaluate their own work/progress. Also daily meetings are a pain in the ass, what works better is accelerating in frequency of meetings as a release gets closer: at the start of a 6-month project once a 1-2x/week meetings are good enough, the week of a major release twice daily meetings may be required.
Methodology? General rule: more risks/unknowns need more iterations. Waterfall is most efficient for an experienced team developing their 20th LOB app in an enterprise of known customers. New team + new tech + new customers? 1-month sprints to incrementally deliver progress is a better choice despite the inefficiency.
Environment wise, triple monitors are the way to go. Most people acknowledge that two monitors are better than one, but three really is the sweet spot. Three gives you one central focus with two periphery that just works better.
Culture is a polite term for clique. Maybe I'm just a bit cynical; but that's how I see it. You don't need to create culture. It happens organicly. You are doing the right thing when 40-something men with kids can code alongside 20-something lesbians and get the job done. What matters is that they can both write low defect code that the other person can maintain. Period.
If you focus on culture, you'll probably just end up creating yet another brogrammer shop. Best case scenario, you'll lose a good dev becasue he doesn't fit your "culture". Worst case, you'll get sued for discrimination.
Start with enthusiastic people. Then, don't kill their enthusiasm with corporate BS.
Keep an open mind - good ideas sometimes come from really whacked out places.
Don't make criticism personal.
Understand that shit happens. Schedules are almost never correct in the first place, nor written in stone: people will not die if you don't ship by whenever.
Keep things challenging and interesting. Who wants to work on a dead-end project in a dead-end company?
Foster an "egalitarian" mindset. Sure, you'll have "alpha dogs" in any office, but people should be free to offer ideas and question others on an equal basis. An idea should stand on its merit, not on the person who's suggesting it.
There are productive meetings and there are not so productive meetings.
I don't think it is intellectualism, its really whether the developer has an inherent interest in software development. Some people get a degree in CS because they have an inherent interest in developing software. Others get the degree because a parent or guidance councilor told them it was a good career path. A B student with the inherent interest will most likely be a far better contributor to your team than the A student who is on the career path.
The question is how to recognize the person with the inherent interest. Its a judgement call but I like to see what sort of stuff they wrote for their own personal amusement or curiosity. I don't really care how trivial or useful such code was. If a person has only written code for school or work projects that may be a warning sign.
Code reviews. Make sure everybody on the team has seen everyone else's code and understands it. Do regular (monthly, bi-weekly, whatever) code reviews. Code quality will go up.
Egoless programming. Don't allow anybody to become a rock star or the only person who can read or write any bit of the code. Everybody must be cross-trained on someone else's code, at least. The team is responsible for the code, so make sure people are polite during code reviews. Polite doesn't mean downplaying problems. It means pointing out problems without being an internet jackass. Nobody "wins" at code review, but the code quality goes up. This works as well as any other software development methodology, with lower overhead, less dedication and no cargo cult behavior.
Professionalism. Foosball tables and other wank infantilize the staff. You're adults, you're there to write high quality code. Keep regular hours, understand that you're there to code, you don't want anybody pulling all-nighters or living in their office. Code quality will go up because it's taken seriously.
Encourage openness. Encourage experimentation. Allow radical changes once in a while. Good programmers want to be understood, respected, listened to and believed. They don't want to be pigeonholed into some kind of geek stereotype, they don't want internet fame and glory, they don't need you to do their laundry for them, they don't need to be coddled.
Reduce (but don't eliminate) time pressure. Code quality wants to go up. It's prevented from going up because management wants you to get to market as fast as possible. Everything you do that improves quality takes time away from feature development. Make it clear that moving deadlines up means fewer features *always*, lower quality *never*. Never sacrifice quality to satisfy a suit.
I've found agile methodology is a great way to spot people that won't be writing software in 5 years. The more people spend their time trying to solve "meta" problems like what is wrong with the software development process, the more likely it is to be a reflection on their own issues with productively writing software. You can take a talented programmer, put them in a room alone, and get good work. You can also take a bunch of "agile" guys, put them in a room, and get nothing but BS about improving culture. Sorry, but programming is only very slightly about culture or methodology, and good coders get stuff done regardless of what is going on around them. If they can't get it done at work, they take it home with them. If their primary job isn't satisfying, then they work on side projects. I've never seen anything get in the way of talented developers. On the other hand, I have seen a lot of excuses from people that don't belong in the field.