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."
Soon we'll be using rasberry pis bought with bitcoins in the year of the linux desktop.
To offset political mods, replace Flamebait with Insightful.
Do I need to tell you I'm joking?
Sorry about the mess.
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..
No micro manages or quotes with NO TPS reports
Let people do work with out all the BS meetings and paper work.
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.
Read everything you can by Joel Spoelsky.
http://www.joelonsoftware.com/
Use the Google/academia method that includes giving them 20% of their work time to purse their own projects
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).
put a couple kegs in the office... don't go crazy with them, but it's nice to know that you can be trusted with grabbing a beer when you want one
Having a "geeky" office with tons of amenities will not do much for attrition if the team is beleaguered with the usual office politics or uncontrolled management pressure that affects many IT and development houses. Based on what I've seen with my few years of working experience, I strongly believe that the most important element in a successful developer-oriented culture is encouraging continuing education and the proliferation of ideas. From what I've seen, this requires having a management team that is *really* good at separating the wheat from the chaff when client or business demands come in and having a team that has very good chemistry with each other. This is really hard to assemble, since it's already somewhat hard to find people that fit what companies want from a technical perspective and harder still to find people that will gel well with everyone else, especially when the pressure cooker starts getting hot and work flows in.
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!
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
Don't be afraid to tell your boss about it. It might save your ass or make you work longer. It also helps a lot to know what your boss knows in terms of contracts, clients. Trying to know about your company really helps as you know if it performs or not. That way you know if you have to look elsewhere or not.
Some lessons that I have learnt from being a developer the last few years: I hope some of them help. Some of them are tech and some are about work culture in general. 1) Developers make mistakes. Don't have a culture of trying to blame things on someone. If you do see problems you can bring it up with the team in general and try to figure out the how to prevent such issues in the future. 2) Try to have lots and lots of documentation. In fact make that as part of your code check in strategy or bring that up during code reviews. 3) Remote working facilities are a must. Most people I have worked with are starting families and need flexibility in work times. Having flexible start and end times and ways to take meetings from home are super helpful. 4) Lastly respect your developers. A good word thrown in occasionally does not hurt. The people I see around me have all put in a lot of effort beyond the usual to get a product out successfully, however, the congratulatory emails always go to the managers with a word for the developers thrown in. A good product really needs a smart and experienced developer. If you keep a culture where your developers hang around because they like to work there, code maintenance becomes much easier.
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.
* Place you can learn. It helps to have smart coworkers you can learn from. If you fit in, they'll learn from you, too.
* No dumb arguments. In some ways this is unavoidable among developers, but I hope to never have another argument about whether the variable should be named 'i' or 'index.'
* Realization that some ideas and designs can be different, but still be just as good as your own.
* Respect. If someone writes code that works, is readable, and is flexible, they deserve respect. Good coworkers have respect for each other.
* Flexibility. Let people finish their tasks on their own time, even if that means they like working from 2AM-10AM. If they like to do good work, don't harass them with unnecessary details.
You know, the kind of "methodologies" that managers use to feel important and sophisticated.
http://programming-motherfucker.com/
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
Play multiplayer games at work in scheduled sessions, great for team bonding and de-stressing.
make sure bug reports have a "who's fault is this" section so you know who to blame. make sure everyone has to fill out a time sheet with their daily activities down to a 15 minute intervals. start every day with a meeting that's a half hour to an hour long so that everyone start work with maximum productivity in mind. make sure everyones personal phone is in a public list so you can call them up at any time and ask questions. oh yeah and a mandatory softball game every other friday after work, people love that, builds unity.
Read books on new development methodologies. Doesn't matter how weird they are - I really liked the "Extreme Programming" book even though I didn't use much of it - but use them for ideas.
Read books on management ideas. Again, it doesn't matter how weird they are; just use them to get the ideas flowing.
Pick the one most promising idea that seems like it solves a problem your team is having. Maybe morale is low, so you kick off one afternoon to have an offsite meeting to gripe about the architecture at a frozen yogurt place, take notes, and use that to begin work on a new architecture.
Keep the ideas in place that work. We added a morning SCRUM to our general process, and it got rid of a lot of aimless development meetings.
Drop the ideas that don't work. We tried to have an all-hands 30 minute code review once per week, and it never worked. The presenter would show off something and people would either be too quiet or constantly asking distracting questions, and the code review never generated useful information. We switched to two-person code reviews - e.g. pair programming - and that worked.
Keep making changes, but don't overload the team.
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.
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 think a more general statement would be to be flexible not dogmatic. To realize the agile is just the buzz word of the day. Like all the processes/methods that preceded it, it has both good and bad ideas. That the best practices touted by all of these processes/methods are sometimes pretty specific to the environment/tasks/workflow that the authors worked in. That the best practices suggested are probably not universally applicable.
Experiment, keeps what works, discard what doesn't.
readily available supply of Nerf weapons
I've nothing to say here...
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.
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.
One CS student VS 893 DOS games: Let's play oldies
Just finished First, "Break All the Rules: What the World's Greatest Managers Do Differently". In my opinion, there's a lot of good advice in there backed up by quite a bit of research.
Good afternoon sex! with your babe boss..
Have you fscked your local propeller head today?
I've only had 2 developer jobs(past & current). Each was entirely different with good & bad things happening. But by far my previous job was the worst kind of place to work for. Even if you forget the fact that we were forced to use outdated tech and the experience there are worthless elsewhere(beyond general software development techniques), it still was a horrible place to work. And that's something I only realized after leaving. So what made all the difference?
1st, I work for a company that sees their employees as their #1 asset. I've seen how they make it a priority to put us 1st over profits. They treat us like adults, not children that have to be supervised or else we will run off with everything including the kitchen sink. They work with us to resolve problems & conflicts, instead of simply letting them fester until the only thing left is firing someone. The key there is that they work with us, not tell us how we will resolve them or discipline us. To date, I've only seen 2 people get fired, and it was quite obvious that they left management no choice.
2nd, my current job is managed by IT people. My boss is an IT grad with an MBA. All of the people I directly answer to either have extensive IT experience or have comparable degrees to my own. This makes a big difference in that they can not only understand the tech, but also the complexities of what is required of us. They also are able to properly prioritize the tasks that ultimately make it to the grunts like me.
3rd, we have Business Analysis-es. They are the buffer between the suits & users and us techs. I can't tell you how much this makes things better for all the techs. When done right, they are able to work with our users when something goes wrong, then come to us to fix actual problems. When there's an improvement or addition that's been requested they are the ones responsible for doing most of the requirement gathering and making sure that the final product works as expected.
Finally, we strive to both keep up with current tech & best IT practices. My company recognizes that its tech is what makes it competitive, so we are always looking for ways to make our stuff better. And because of the 1st 3 reasons, what we techs say carries weight.
If you want to see how not to do things, go look at the DailyWTF. There's plenty of examples there to see how even the best intentions can go horribly wrong.
Research has shown that the only way to produce high-quality software faster than anyone else is to hire top-notched programmers. Top programmers always outperform average ones regardless of the methodology, language, or platform they use. If you want to be the best, hire the best.
Don't stop where the ink does.
The most important part of developer culture I look for is an emphasis on training. I'm flexible as to culture, development methodologies, etc., but without education, my resume could get stale enough to trap me in a job I no longer want.
The continuing education doesn't have to be expensive ('college courses'). One-day seminars, internet training, or even presentations on a topic by other developers in the company, can help keep the skillset up-to-date .
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.
I like it. I use it. I have some. I keep it in a jar above my refrigerator. I'd like to put some more money in that jar. That's where the employer comes in.
Floating in the black seas of infinity without a paddle.
You need to hire a middle aged ex IBM or Apple manager who doesn't code but is very good at playing politics.
Oh wait, that's the way to completely fuck up a small company.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
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.
Hire older, wiser people. They will already know the answers to all of your questions, and lots more.
For me, a quiet environment. Few interruptions. I greatly prefer 0 interruptions. Planned collaboration is not the same thing as a stream of interruptions which prevent me from ever concentrating.
1. Don't be too stuck on particular things - multiplayer games, ping-pong, etc. Do whatever works in your team.
2. You need a good manager. If you don't have one, forget it. You can get good teamwork, but it's also sorta like saying you can fly through a highway tunnel like they show in the movies. If this guy isn't encouraging good behaviors and values and discouraging bad ones, well, it's roll of the dice. This is the single most important factor, not the people [currently] in the group.
3. Stamp out and destroy arrogance and aggressive behaviors. This is the single most destructive thing in development groups - people who know very little pretending to know a lot, and pushing others around. This isn't just interpersonal - it costs companies lots of money and drives away good people. Note that avoiding arrogance doesn't mean pretending you're stupid. There is a good analog with humility. Humble people seek primarily to not put themselves first. Instead of always putting forward what you know, look for what you don't. You get better solutions and spend your time doing more productive and useful things.
4. Be highly competitive with yourself, but not with others. Think coopetition: it produces better results than competition.
I recommend you read up on what this guy had to say about operations and engineering.
You may find many of his ideas surprisingly applicable to software development.
People with a real affinity for inventing and building things with code seem to work out pretty well. An innate curiosity about how other people do things, and why, is something to look for too. On the teamwork part, it works best if you can find someone who is able to listen to other people's perspectives. Time and again we get people in the door who look great on paper but cannot work effectively with other people. If you keep someone like that staffed, it eventually sinks the boat. Oh -- immediately pass on anyone who uses the word 'bro' in a sentence.
Join the Slashcott! Feb 10 thru Feb 17!
Good pay, lots of time off, an emphasis on quality over quantity, and make it clear to devs that you must both a.) do good work, and b.) not be a dick. Do that, and the rest should take care of itself.
I'd like to emphasize that what works varies from person to person, not just from group to group. That despite what the currently in vogue development model tells you, best practices are not necessarily universal. Two highly skilled developers may have radically different best practices. That forcing a single set of practices upon a team may adversely affect the performance of a particular individual. The team leader needs to recognize such situations. For example one agile/scrum school of thought may advocate breaking work into very small tasks that are somewhat randomly assigned, a particular developer may bounce around different parts of the program from task to task. This works for some, not for others. Some skilled developers are far more efficient if they get the chance to specialize in a particular area for a while. Others may get bored doing so and prefer the bouncing around the project. Others may be indifferent. Don't fight against what works best for the individual. And make sure you communicate why some are working in one manner and others in a different manner, that its a matter of their individual styles not some sort of favoritism.
In my experience, nothing degrades morale like producing (and then having to maintain) poor-quality code. A culture that encourages people to do things right the first time will go a long way toward preventing developer burnout.
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.
Think like a tribe and do things to strengthen the tribe. A culture is strengthened by rituals and mutual goals, so do things that reinforce that. Divide your culture into three areas: 1) Work, 2) Play, 3) Philosophical; and do things that will reinforce those. Here are some specific recommendations:
Work
Adopt development methodologies (like Agile) stolen/gleaned from well-documented sources. Adopt specific syntactical coding standards so that everyone's code looks identical. Do not permit anyone to use tools to make their code "pretty". Have inclusive meetings to hash out the specifics and get complete buy-in from all team (tribe) members. Document well for future members. More specifically, institute weekly code reviews (at least until they start becoming pointless because everyone is finally on the same page) where one person's code is examined and discussed. This is a ritual that exposes egos, reveals misunderstandings, and exposes weaknesses that can be remedied. After a few cycles through everyone in the team, this will become less difficult and there will be far fewer issues found. Pro tip: start with the tribe leader's code. New members will view code reviews as a kind of initiation, which it is. I was on a team of five developers that did this and it did more to bring us together as a tribe than any single thing. Caught tons of bugs well before they were integrated into the rest of the system. (Initially, we could not check code in until it had been reviewed.)
Play
Eat lunch together as a tribe at least once a week if not more often. Eat in the office and play poker, (not for money) if possible. Always invite everyone in the tribe and if you have a lone wolf that never eats with everyone else, have his boss start holding work lunches, requiring attendance (and then just don't do any real work). Similarly, have some kind of family friendly weekend, off-site event at least once a quarter, paid for by the company if possible, such as cookouts, bowling, sporting event. Ideally, this will be more picnic-like than movie-like to foster getting to know families. I was part of a team that did this (not the same as the one mentioned above). Picnics, a softball team, a volleyball team, movie days (we'd take a long lunch and all go to a new release) were all part of it. It was great until we merged with another company that took over, trashed our budget for such things, split the tribe, started having conference calls during lunch time. Tribe hung on for a while but once these changes were in place, it was clear to us that the company that took us over had no soul.
Philosophical
Have regular "meetings" to discuss technology trends, ideas, stuff found on the web. A lot of this will happen at those regular lunches but try to let lunch be more social, less work talk. As individuals, investigate new methodologies and tools to adopt and then discuss them in a group. Find out what websites each of you regularly reads. Tell war stories from previous jobs or college. Think of these meetings as the time to plan how to strengthen the tribe. The atmosphere of these "meetings" should be akin to sitting around the campfire, sipping on a beer, smoking a pipe, looking at the stars, telling stories. The agenda is not about getting anything done for work, but just about sharing thoughts. Don't let looking at the web become the focus. If no one is talking, then you are doing it wrong. Meeting once a week should suffice.
Note that all three activities above will go far to introduce new team members to the culture and get them integrated into a productive environment. This is important in the long run as rapid team growth can kill a culture. These activities go far to reinforce hierarchy and retain the culture, as well as identify issues that new members may bring along as baggage.
As a species, we are wired to be social and our social construct is wired to be tribal, both in size and in hierarchy. Also, our tribal roots center on the meal, so adding food to any of t
the #1 thing in my view is to have a period set aside, so that Developers can work on/learn/develop something new, which may or may not be directly applicable to the project at hand. - it should (preferably) at least have some relationship to software development - it doesn't have to be a lot of time - even say an hour a week, or one Friday afternoon a month. At Google, employees get 20% of their time to work on whatever they want. - the developer has to report back his findings to the rest of the group
motivated people.
The Kruger Dunning explains most post on
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.
Key for me: -Good pay/benefits -Competent management that doesn't micromanage -Flexible scheduling and a thought process along the lines of "you don't necessarily have to work 40 hours a week as long as you are getting your work done". Obviously, though, if someone only "needs" to work 10 hours a week they should be asking for more work...there has to be some common sense about it. -***Hiring people who can handle not being micromanaged and can be trusted to ask for more work and not abuse the flexible schedule.*** I feel very lucky to work where I do. Management trusts us and while things aren't quite as flexible as I'd like (WFH is mostly a no-no), our work-life balance is really good and the cherry on top is a decent wage/good amount of vacation days.
"Fire the assholes"
I've worked in a dozen or so small-to-mid software shops as employee, contractor or founder. The number one (preventable) reason for companies to go under, in my experience, is one or two jerks poisoning the well.
No matter how awesome someone looks on paper, if he or she is making people around him or her resentful, fearful or angry, pink slip immediately. Don't mess around. Don't worry about loss of capability - ask your team to step up and fill in until a new hire can be brought in, and they will.
Nothing kills team spirit more than that one guy who thinks primate politics trumps respect and results.
Looking for a Rails developer in Chapel Hill?
Research shows that pair programming increases productivity only for novice-novice pairs. For novice-expert or expert-expert it is a net drain. Code reviews with 2-4 reviewers are more efficient and produce better quality than pair programming.
I've lead and followed in software development, ranging from junior guy to Sr. Development Manager. Here are a few points that I've picked up along the way that help:
- Clearly define career paths for your developers. It's ok if that path ends at some point. Not every position can lead to CEO, but there should be a clear bar for those wanting to grow.
- Create Individual Development Plans for your team members to help them reach those goals. Include realistic metrics, not vague "Do good!" statements
- Provide training as a normal part of business. Don't wait until you have to use a certain technology and then cram everyone into a room to learn it. Be proactive.
- Offer paid travel to conferences in place of training for those that prefer it. They usually come back with ideas or areas of focus to better process, development tools, and products.
- Don't let drama fester. If Bob is always leaving early and people are grumbling, talk to Bob.
- Don't resort to the mass-email to avoid confrontation. If Bob continues to be a problem, don't send a generic "Team members should be on time and leave on time" message to the group. There's no better way to kill team spirit than to lecture them all over the actions of a few or one.
- Don't get caught up in perks. Pay a reasonable salary, and be a fair company, and you won't need the goofy team builders.
- Don't let your employees walk all over you. If you need them there 40 hours a week, doing a professional job, tell them that. Don't bow to their will because you think it will make them happy. It often won't. What will make them happy is knowing what to expect. You can't let them show up at noon every day for three months and then decide to get pissed off about it. State the rules up front, keep them simple, enforce them every time, and be fair across the board.
- Remember that they're all grown damned adults. They are probably quirky in ways, but they wouldn't be there if they weren't also intelligent and valuable to your team as a whole. Treat them with respect in everything you do and you'll most likely get the same in return.
- Remember that you are there to support them, they aren't there to support you. They are there to deliver something for you, and your job is to help them achieve that. Flip the org chart upside down if it helps you remember.
I could go on for hours, but I'll cut it there.
The single biggest flaw I've seen is not understanding what a team is. A team is not just a bunch of people with complementary goals. A team means people are invested in the performance and success of their team mates, and are constantly sharing information and supporting each other.
Being a team player is not, however, going beyond your contractual obligations to compensate for the bad planning of others.
UML is critical for many difficult system interactions. A single diagram can save several refactors later.
Unit testing is critical for good code. The point isn't to reduce defects the first time out of the gate. It's to reduce the likelyhood of problems being introduced the n'th time you have to refactor or expand an area of your application and need reasonable assurance that the impact of the change doesn't have a large footprint. You can change or add what is needed, run your tests to green, and be fairly certain that the application functions as intended in all tested areas. Otherwise, you're relying on instinct to tell you what the real effect on the applicaiton may be.
Instant messaging depends entirely on the culture and nature of your group. If your team isn't colocated it can be invaluable for every day work.
Git is no more a fad than CVS, Subversion, SourceGear, VSS, or any other source control. Source control is necessary. Your particular flavor of it may differ depending on your product, IDE, and approach. I like Git, but use Subversion more. Neither is a wrong answer, depending on the situation.
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.
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.
Keep all your developers focused on the problems you are solving. The really hard problems. And demand clarity in their code and solutions. In the end, the problem is the vehicle towards the value you are producing. Leadership's role is to define and communicate a vision of the value you produce, the engineer's role is to understand that vision before but necessarily thereafter identifying and solving the problems that expose their solutions and result in the delivery of the value.
If process or any other factor of the work place start to reduce developer focus from problem solving you will disable or lose your best people and accumulate slack-jaws. Having a job that actually keeps your brain revved up and challenged on an every day basis is crack to true geeks. Note that the basics like reasonable compensation, a good development machine, and basics like coffee et cetera are important to make sure no issue invades the mind space of your focused problem-solving employees.
Having worked in both a successful startup and a large corporation, this is what seems to hinge or turn any effort in our field.
*) 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.
1 Any time you start hearing tocatta and fugue in d minor make sure you start getting supplies to comp for the extra stress on your team (Snax and Soft Drinks for the team would be a start)
2 make sure that marketing does not OverSell The Product
3 if you have Married Team Members you may want to setup some sort of OnSite Daycare (this is a MUST if you have Female Married Team Members) even if this is a spare conference room with an On Call caretaker.
4 treat your employees like people not like Droids (unless 3-CPO or Rommie actually apply that is)
Any person using FTFY or editing my postings agrees to a US$50.00 charge
Everything but the last sentence absolutely disgusts me.
Are you interested in making developers happy and feel good, or interested in producing good (great?) products? The two are not necessarily complimentary.
A faithfully used bug tracking & task assigning tool will give great accountability of what people are working on, where the product is in the schedule, prioritize tasks, etc. But using it may be considered burdensome micro-management by developers. A "good" developer should want to use those tools, though.
I interpreted the question along the lines of tools that should be available and used by the development team. Trackers, continuous integration, VMs, debuggers, source-control, IDEs, that sort of thing. Provide a rich, discipled set of software development tools, enforce consistent use, and teach the newer guys to use them.
Whether you have Hawaiian shirt day or free Red Bull should be pretty far down the list of concerns. Free drinks & snacks are nice, though, as they make being in the office a bit more comfortable. That sort of social, interpersonal thing is definitely going to be different from group to group - even within an office. But the company recognizing the importance of that social bonding and allocating some time and funds for it is certainly a moral booster.
In summary:
1) First focus on the work. Provide the tools to do the work well. Make people use them and teach people to use them.
2) Provide some personal social tradition to help the group bond.
- Jasen.
I'm not going to claim that there aren't a lot of other things you need to do for good "culture", but one basic thing I see screwed up in most companies is always the same thing. Lack of communication. Not just programmers, just about every company in every department has a problem with this. The more people are allowed to speak, and people LISTEN to them, the better your environment will be.
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.
There are definitely things you can do to bring a team together and promote a better culture, I feel there's a certain organic quality that has to be present to make a truly good working culture. It comes down to the team members inherent qualities and their own definitions of what makes a "good" culture. Luckily, your team is quite small, so you should be able to do this with relative ease. Make sure the business is in order, then sort the rest amongst yourselves... preferably over beers.
Nah, arch on a thinkpad. 12 hours of battery means I can sit wherever I want without an outlet and just plug the sucker in overnight. Even sticking between 20% and 80% charge, I can get at least 6 hours of coding, surfing and e-mail without breaking a sweat.
If you're not worried about being mobile, then just about any desktop will work, just give us a decent resolution monitor and a non-chicklet keyboard with a number pad.
Try to make it a place where it's okay to fail, and fail early. I don't mean encourage people to be idiots, I mean make sure it's okay to try, work hard, make a legitimate mistake, and everybody moves on without repercussions and hopefully there's some lessons learned.
First, as a good developer, you need to check your assumption that this problem is a good target for optimization. You need to assess, as best you possibly can, if what you are accomplishing meets an educated best guess as to what your output would be in an ideal sense. That's how you optimize systems. You don't waste a bunch of time optimizing things that are functioning at full capacity. As far as why people come up with new methods, there is a lot of money in it, and there is constant pressure to find ways to increase productivity from developers. However, just because the pressure exists doesn't mean that it's a good idea to spend a lot of time optimizing a system that quite possibly is already at it's limits.
The next thing you need to remember is that statistically, the chance that you will be writing software at age 40 is slim. Choose how you spend your time wisely. I can't tell you how many younger developers, many of whom won't even be in the field five years from now, spend a significant chunk of their careers on problems that are unsolvable (like making a significant improvement in software methodology), rather than making a significant contribution as a programmer. My advice, spend your time on solving problems that are feasible, instead of chasing pie in the sky dreams of solving a problem that we can hardly even describe, much less solve.
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.
Crotchety bastards who will inject some maturity into your team, then sit down and crank out top notch code for 8 hours.
I am very small, utmostly microscopic.
- Comment your code religiously (i.e., what a given piece of code is intended to achieve, why you chose to do it that way, links to relevant materials, etc. as appropriate).
- Take unit testing and regression testing seriously. Make it part of each work item.
- Keep your designs simple. This takes careful up-front thinking. Avoid design patterns unless you absolutely have to use them (they mostly add complexity to little benefit in my experience).
- Try not to jump on bandwagons. Be skeptical of everything in the industry.
- It's a team game: write for each other, leave your ego at home.
- Have a team pub lunch at least once a week.
i also work on a small development team and believe that there are distinct aspects to culture that promote success. just saying the word "Agile" is not enough. software releases are not a stunt where we work up to a frenzie of effort and shove it out the door hoping it works. software development on our team is a sustainable lifestyle involving a constant reasonable level of effort producing a steady level of output. we have delivered 10 production releases per year for about 11 years and perhaps we have worked past 9pm 3 times in the previous 4 years. you can try to glorify how 25 year-olds can stay up hacking all night and do wonderful things but that is not a role model for the majority. most professional developers also have outside lives and even (gasp) families that they might like to see. one key factor that enabling us to maintain both productivity and social lives is a strong defense of the work pipeline. we know how much technical work our team can fit into one release and we say NO to everything else. because our releases are frequent, it lowers the stress of putting items off until the next release. even so, our managers are sometimes required to use an iron fist defend our capacity and refuse to allow us to become overwhelmed. this is a central part of our culture, our managers never succumb to external political pressure to work us into burnout and in exchange we dont slack off during the reasonable number of work hours we give each week. the result is sustainable productivity and essentially zero turnover traceable to burnout.
I've worked in a lot of different environments, in some as lead, and in some as the coder. I've seen some things which work, and a LOT of "fail."
This is what boils down to: The mission must be more important than anything extraneous to it, and the people must be more important than the mission. NOTHING beats motivation to succeed (not even money).
The "show must go on" attitude (as long as it does not trample on people's lives) really helps to cull the nonsense. Have fast release cycles, and make sure customer feedback is immediate and visible to the team. Do not isolate the team from the end-user. It really helps to have everyone have a sense of ownership in the project -- developers get turned off and start reading Slashdot if they do not see the impact of what they produce.
Encourage new ideas, and listen to people when they speak in areas of their own expertise. Make sure there are several larger steps to be taken after the immediate project, and a grander vision for what the team is trying to accomplish. Development methodology, etc. is team specific -- find what works for your specific team.
Get rid of the jerks, cynics, and fanatics as soon as possible. Make sure you yourself are not in these categories!!!
Foster a sense of teamwork. Keep the team socially engaged with each other. Take them out to lunches, dinners, drinking, etc. Send them to conferences to demonstrate the product, if this is applicable. If they can't stop talking shop during these events, you're doing it right :)
I've learned over the years that a good company culture actually makes a difference, as long as it's real, not some artificially created one. Of all possible values in your culture, I've found that 'fun' was the most important one. From that, dedication and shared responsibility follow naturally.
Furthermore, I think you're on the right track by keeping your team small, adopting an agile practice to stay focused. The challenge with the latter is, you have to be really honest to see what works, and what doesn't. Retrospectives are more important than anything else.
Oh, and be a catalyst for change in the rest of your organisation.
I spent almost two decades in an older development environment, and can share some of our prized secrets for success. It helped to have a team lead who was REALLY good with threats and verbal abuse. Everyone needs "Ivan the Terrible" role models to help foster a nurturing environment of back-biting and finger-pointing. Another secret is to always replace a programmer who was not a good fit, with another even more dysfunctional misfit. Lead from behind. Set your best people up to fail. When forced into a product upgrade, poll the clients to ascertain what they don't want, and give it to them. Have your system architects study Machiavelli. Never fix code when a kludge or spaghetti code land mine can be concealed for the benefit of future generations. Programmers, make sure QA or beta testers follow scripts YOU control, or else they'll be wandering off on fishing expeditions to find inoperative features and broken functionality. Make sure all your people understand that broken GUI's and grossly inaccurate algorithms are "working as designed." Above all: the healthy development environment will insure that everybody, from VP to administrative support, lives in fear of their job and absolutely dreads going to work every morning.
Rubbish. We'll download a file and print our own at home!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
You're almost right, but the main problem is when a team gets obsessed with other issues than actually writing code. You want as little time as possible to be spent on debugging and rewriting. In order to achieve that you need some tools. To avoid rewriting you need some way of specifying what the software is supposed to do before actually making it. UML can be used for that, but it's not a goal in itself. To avoid endless debugging session you need tests, unit tests can be used, but I've found it far more productive to write code that has a lot of debugging code in it. Since I'm mainly writing C/C++, this will be in the form of asserts and #if DEBUG ... #endif, but the main idea is to catch errors as early as possible during program execution. In my experience it's far more productive to get dedicated testers to test end-user functionality and file bugs than to make the programmers who wrote the code write code that checks if the code they wrote did what they thought it should do. The reason is that most bugs occur because the programmers who wrote the code failed to consider some particular corner case when they wrote the code, and they will likewise fail to write a test to test it...
In conclusion, the primary goal is to develop a product, not to write tests, not to make specifications and not to make clean revision histories. However, when used right, specifications, testing and version control enables you to develop the product faster and with higher quality.
The interactive way to Go -- http://www.playgo.to/iwtg/en/
Never been in management. Ever. I write code.