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."
culture? (Score:5, Funny)
Re: (Score:2, Funny)
... reading about it all on SlashBI and SlashCloud.
Comment removed (Score:5, Insightful)
Re:culture? (Score:5, Funny)
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.
Re: (Score:3)
I worked at a place like that and they went down in flames. At my current job our total code base is only about 1 million lines of code that runs on OSX, linux, and windows. The difference is we do it with three people, and we also serve as IT for the lab. In and of itself that's not a big deal as the amount of code per developer is similar to your organization. The major difference is that we get it done in 8-10 hours a day Monday through Friday, with weekends off, and 6 weeks totals of paid vacation/h
Re:culture? (Score:5, Interesting)
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.
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.
Re: (Score:3)
We are not talking about individual developers. This topic is about providing an environment where people can do their best. A good developer should not have to take stuff home to work on if the environment is part of the workflow, instead of an impediment.
Hiring the right people and firing the right people is a great way to start, but it's often very hard to do. Giving the developers some flexibility to choose their methodology, whether it's agile or something else, goes a lot further than telling them
Re: (Score:2)
Not reading /. (Score:2)
Good Development Culture (Score:5, Interesting)
Re:Good Development Culture (Score:5, Informative)
This truly belongs in the category of questions that if you have to ask, then you're not going to understand the answers...Mostly because they will be of the same caliber as the question.
Re: (Score:3)
Must be Barnum's Animal Crackers. I think they are the only ones that have seals (and giraffes)
Re: (Score:2, Funny)
An emphasis on keeping high-quality & intelligent developers. Don't ever let intellectually lazy developers onto your team.
We have a solution for lazy developers. Well, a solution for the whole team. Keeps things simple:
We're adding a little something to this month's developer salaries. First prize is a Cadillac Eldorado. Anybody want to see second prize?
Second prize is a set of steak knives.
Third prize is you're fired.
Re: (Score:2)
"Don't ever let intellectually lazy developers onto your team."
Or, at least let those developers know that they should start changing their approach -- and have some leverage and resources in achieving that goal. Beware of standard push backs: if you address issues of efficiency or design, there will be a push back in terms of "timeliness". Worst case is if higher ups don't want to be bothered with any of the underlying process related issues.
If you are in the middle position where the higher ups do not car
Its inherent interest, not intellectualism (Score:5, Interesting)
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.
A CS/CIS/etc degree is not required (Score:4, Informative)
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.
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.
No micro manages or quotes with NO TPS reports (Score:2)
No micro manages or quotes with NO TPS reports
Let people do work with out all the BS meetings and paper work.
Re:No micro manages or quotes with NO TPS reports (Score:4, Insightful)
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.
Re:No micro manages or quotes with NO TPS reports (Score:5, Funny)
Re:No micro manages or quotes with NO TPS reports (Score:5, Funny)
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.
Re: (Score:2)
Re:No micro manages or quotes with NO TPS reports (Score:4, Funny)
Re:No micro manages or quotes with NO TPS reports (Score:5, Interesting)
There are productive meetings and there are not so productive meetings.
Comment removed (Score:5, Insightful)
Re: (Score:3)
"Most meetings should involve two people. Sometimes three. Rarely more."
I disagree. Meeting need the person calling it to be a moderator, anyone would be able to call it when it starts to loose track, and develop a culture that respect those 2 rules. Some thing s are really to complex or require too many disciplines for meeting that small.
"Any meeting that involves more than three people should be done standing up."
Don't be an ass.
"Anyone should feel free to excuse themselves from a meeting when they feel t
Re: (Score:3, Funny)
Oh man! Hahaha! Whoosh on me! I laughed pretty hard when I finally realized that everyone was actually talking about sex.
Re: (Score:3)
But meetings do serve a good purpose in a company like the plans on what to do next,
A bug tracker + email is better.
whats going on right now,
Bug tracker + email
the reports,
Email
all those things a boss and other employees can communicate to each other when they don't have time.
Email + Instant messenger
Benefits:
1. Fast responses in general (don't have to wait for the meeting)
2. People can respond when they have time (doesn't disrupt work)
3. Doesn't take any time if you have nothing to say (no pointless meetings)
Re: (Score:3)
Email + Instant messenger
Benefits:
2. People can respond when they have time (doesn't disrupt work)
Only if your boss doesn't ask 5 minutes later why are you not responding to email.
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:No micro manages or quotes with NO TPS reports (Score:4, Informative)
Only stuff from category A should be send via e-mail. Everything in B and C you throw on a wiki, bug tracker, reference docs, etc so they can look it up themselves when they need it (instead of when you decide to send it). The only exception is a quick 1 line e-mail saying "the informatin regarding FOO you have been waiting for is now available at BAR" with a link to the resource.
Not only does this keep the e-mail volume low (and increase the chances that your employees get the information they need), it will also help centralise and enforce your documentation instead of fracturing it among 10 employee inboxes.
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.
Varies from person to person, not group to group (Score:5, Insightful)
Re: (Score:3)
I worked for a company that liked to pride itself on its "culture." They had a pool table in the office that you could play any time you felt like, free sodas, etc., etc. And in particular, it would throw elaborate parties every few months that were really thinly-disguised recruitment efforts. At one party, they rented a room full of vintage videogame cabinets and turned the office into an 80s arcade. At another, they had a car theme where they rented a large-scale remote control car track that people could
Re: (Score:3)
+1
Culture DOES vary from company to company, department to department. A culture is defined by a bunch of things: what behaviors are rewarded, relationship between employees and managers, relationship between employees, where is the focus (outside innovation and productivity or inside atmosphere and procedures?). There is no single 'correct' culture for developers, it really comes down to what kind of culture the developer wants to work in. Some developers want innovation and creativity to be the focus,
I Can Tell You What NOT To Do... (Score:5, Interesting)
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.
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.
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.
Stay away from agile (Score:5, Interesting)
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.
Re:Stay away from agile (Score:4, Interesting)
Re: (Score:2)
I understand this argument, and I'm honestly not trolling, but what about the times when bitching is warranted and demands resolution?
If there is a developer complaint that design is dictating functionality that is out of scope, sales that is not accounting for that in the contract, and a developer that ends up need an extra week to implement the design, then yes, process needs to change or it's mostly downhill from here.
That said, sure, you can begin looking for work elsewhere, or you can stand up and bi
Re: (Score:2)
And refining the process is indeed something that everyone works on. And there IS a level of bitching from all directions. But once there is more bitching than working... well that's a pretty bad sign.
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.
Re: (Score:2)
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: (Score:2)
well what is agile? wikipedia defines it nowadays as "a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams".
the page even has a fucking spiralish picture on it, but that's not the point. the point is the roots, which is to just get it done - if there's a problem in the specs skip waiting for your departments deadline, skip waiting on everything - go directly to the
Re:Stay away from agile (Score:4, Interesting)
Counter-anecdote:
The company I work for is very successful and has a great geek culture. We use agile methods and it has been working very well for us. We design and develop new features (and fix bugs) quickly, and we always ship on time. We're hiring like mad and can't get enough good developers in the door. I'm not going to name the company, but we hit the front page of Slashdot once in awhile.
The key is to pick the parts of both traditional development management and agile that make sense for the team and the product. For instance, some teams scrum every day, but my team only scrums twice a week. You can't buy an Agile for Dummies book, force the whole thing upon your developer teams, and then expect your productivity to skyrocket. Even when you think you have a good recipe, it should be constantly evaluated and tweaked or reworked when necessary. The whole point of Agile is to be flexible enough in your methodology that you can scrap or replace what doesn't work.
My advice to the submitter: Feed and water your hackers. As in, provide an unlimited supply of snacks and beverages. Bring meals in occasionally. Don't say no when they ask to put a MAME cabinet in the break room. Encourage them to socialize on company time. Let them work on side-projects which benefit their workflow. Avoid hiring managers from outside the company when possible and prefer to groom the smartest individuals for management positions if they're interested. Above all, give your lower-level managers and developers clear and realistic goals and an abudance of freedom to decide how to best meet them.
Re: (Score:3)
implement waterfall in a iterative process
That is agile. That's exactly all it is.
I don't dispute the value of your experiences, but maybe learn what you are talking about before offering advice to others.
-- 77IM
Joel (Score:2, Informative)
http://www.joelonsoftware.com/ [joelonsoftware.com]
Re: (Score:2)
Beware the Agile/Scrum Zealots (Score:5, Informative)
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).
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.
ideas and what your boss knows (Score:3)
Re: (Score:3)
Forgot to tell but this is kind of a hard one to do but seriously helps the company and you. Try to know what your bosses clients wants and needs that way you as an employee can start gaining the neccessary knowledge you need. Lets face it, you could get the kind of boss that if you don't have the required knowledge you can get fired and he can hire someone else right away or can start licencing work elsewhere and in the end, that's less work for you or it can be very risky for employees.
Just for example,
Tips (Score:5, Insightful)
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.
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.
my thoughts (Score:2)
* 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 resp
Lack of "methodology" (Score:2, Interesting)
You know, the kind of "methodologies" that managers use to feel important and sophisticated.
http://programming-motherfucker.com/ [programmin...fucker.com]
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:Intellectual honesty (Score:5, Funny)
Agree with most of this - but I would also add variable width fonts to the list.
Re: (Score:2)
Agree with most of this - but I would also add variable width fonts to the list.
No, the GP is implicitly saying that programmers in the PROPER developer culture use monospaced fonts to keep the indentation levels consistent.
Re: (Score:2)
Or to put it more clearly, there is an inverse relationship with money+timelines and intellectual honesty.
Add New Ideas Gradually (Score:2)
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
Good people = good environment (Score:4, Interesting)
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, 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.
Nerf (Score:5, Funny)
readily available supply of Nerf weapons
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.
When trying agile, use retrospectives (Score:4, Informative)
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.
Nothing beats.. (Score:2)
Good & Bad (Score:2)
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
Hire the Best (Score:2)
Continuing Education (Score:2)
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... (Score:2, Interesting)
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 de
Re: (Score:3)
Pay well (Score:2)
Management (Score:2)
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.
Attitude (Score:5, Interesting)
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, Git... (Score:2, Informative)
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 (tim
Re: (Score:3)
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
Deming (Score:5, Insightful)
You may find many of his ideas surprisingly applicable to software development.
Good developers (Score:2)
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 pa
Easy (Score:2)
hacker time (Score:2)
little managment (Score:2)
motivated people.
code reviews, professionalism (Score:2, Interesting)
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 poin
3 Words (Score:2)
"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,
Just my thoughts. (Score:2)
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
Teamwork (Score:2)
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.
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.
Culture HOW-TO (Score:2, Informative)
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.
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.
make sure you keep Reality Checks in stock (Score:2)
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
Developer Culture or Product Culture? (Score:2)
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
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: (Score:3)