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'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.
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.
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).
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
The solution is obvious: have a meeting to discuss the usefulness of meetings.
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
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
There are productive meetings and there are not so productive meetings.
The solution is obvious: have a meeting to discuss the usefulness of meetings.
Yes but you can't rush right into a meeting like that. Often it takes four or five pre-meeting meetings before going into a meeting like that.
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)
meh... prior to my current job i would have agreed with you 100%. But I've actually stumbled into working somewhere that actually does have a culture. Everyone here is willing to put in as much time as it takes to make our clients happy; including staying up until 4am for a load test one night and then waking at 3am for a meeting with an overseas client the next. We've had people hop on and help troubleshoot while at the hospital and vacation, and drive hardware to other states over their weekend. More importantly, there is never a boss forcing or even asking it to be done, we just do what we know is needed. Co workers are open to receiving and dishing out honest opinions - no matter how harsh - and build stronger relationships with other on the count of it.
It may sound gruesome, but that is where the company embracing culture and its employees comes in. While we are semi expected to be in the office between 10am and 6pm, there is no one watching or caring what time you leave or come in - so long as you're getting your job done. Hell, we don't even track time! Any given night there is at least a few of us out having drinks, and even working from the bar. And more importantly, we are all very accepting. Anyone busting their asses is welcome, with open arms. Our office has a full service coffee bar with a barrista (free), free soda, free snacks, ping pong tables, several arcade machines, a theater and buys lunch for everyone every friday. We have no internet filters or people watching our activity. it's not all that uncommon to see people on facebook or reddit or even playing a video game. It's not uncommon for nerf gun fights to break out, or coworkers facebook bombing each other. Again, all that matters is performance. We all recognize that some weeks are 80 hours of chasing fires, and others are spent dicking around. Working from home is accepted, so long as it isn't abused. And even then they deal with it on an individual basis rather the typical all-encompassing "new company rules" approach. There are no "designated smoke breaks" and no one bitching about the smokers (myself being one have been previously unaccustomed to not constantly hearing that crap). Internal meetings are full of cursing - with our CEO being the biggest potty mouth. In fact, we make it a point to drop as many 4 letter words as we can during interviews to make sure the candidate isn't uptight about that kind of thing.
This may sound like an impossible environment to work/be productive in... but our flagship product has over 30 million lines of code, we have a hosted environment with 5 datacenters globally + EC2 overflow + PCI walled gardens, and hundreds of premise clients as well - all of which we support 24/7 without discrimination or cost to the client. And since our product is the backbone of many solutions, we have to deal with nearly every type of language and tech out there. python, ruby, groovy, java, C, php, opa, ccxml, vxml, html, groovy, js/jquery, etc. Even better, the purpose of our product is to parse/render many of those languages, it requirs a fairly deep understanding of them, and constant learning... we have to work with ALL db's, OS's, web service types, packet analysis, working with various carriers and telco's and hardwares, etc. . All done with around 100 employees, total - which only about 60 are technical.
TL;DR - free/happy employees make the best employees. Just make sure you focus on hiring/keeping the aces.
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.