Slashdot: News for Nerds


Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: What Defines Good Developer Culture?

Soulskill posted about 2 years ago | from the dim-lighting-and-shorts-in-winter dept.

Businesses 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."

cancel ×


culture? (4, Funny)

masternerdguy (2468142) | about 2 years ago | (#40497083)

Soon we'll be using rasberry pis bought with bitcoins in the year of the linux desktop.

Re:culture? (2, Funny)

Anonymous Coward | about 2 years ago | (#40497167)

... reading about it all on SlashBI and SlashCloud.

Re:culture? (-1)

Anonymous Coward | about 2 years ago | (#40497921)

Harvard overlord harvard overlording [] Where chicks know their role.

Not reading /. (1)

genghisjahn (1344927) | about 2 years ago | (#40497091)

Do I need to tell you I'm joking?

Good Development Culture (5, Interesting)

TheNinjaroach (878876) | about 2 years ago | (#40497147)

An emphasis on keeping high-quality & intelligent developers. Don't ever let intellectually lazy developers onto your team.

Re:Good Development Culture (4, Informative)

DrVomact (726065) | about 2 years ago | (#40497241)

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:Good Development Culture (2)

sinan (10073) | about 2 years ago | (#40497551)

Must be Barnum's Animal Crackers. I think they are the only ones that have seals (and giraffes)

Re:Good Development Culture (1, Funny)

alphatel (1450715) | about 2 years ago | (#40497795)

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:Good Development Culture (1)

sisukapalli1 (471175) | about 2 years ago | (#40497929)

"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 care about the process, and the developers are a bit lazy and complacent (e.g. "I am fine as long as the higher ups are happy"), tough luck!

Its inherent interest, not intellectualism (4, Interesting)

perpenso (1613749) | about 2 years ago | (#40498083)

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.

Re:Good Development Culture (3, Insightful)

Tough Love (215404) | about 2 years ago | (#40498163)

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 (1)

Joe_Dragon (2206452) | about 2 years ago | (#40497189)

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 (4, Insightful)

fluffythedestroyer (2586259) | about 2 years ago | (#40497265)

But meetings do serve a good purpose in a company like the plans on what to do next, whats going on right now, the reports, all those things a boss and other employees can communicate to each other when they don't have time. Meetings do serve that purpose and others like acting as a guide or a light in a big ocean as it's very easy to lose track. Taking 30-60 minutes per week minimum can help a company a lot since most of the time they work and don't have time to talk to each other. Just don't have too many since employee might get pissed off and demoralized by it.

Re:No micro manages or quotes with NO TPS reports (5, Insightful)

silas_moeckel (234313) | about 2 years ago | (#40497383)

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 (5, Funny)

seepho (1959226) | about 2 years ago | (#40497493)

The solution is obvious: have a meeting to discuss the usefulness of meetings.

Re:No micro manages or quotes with NO TPS reports (5, Funny)

Troyusrex (2446430) | about 2 years ago | (#40497881)

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:No micro manages or quotes with NO TPS reports (3, Funny)

w_dragon (1802458) | about 2 years ago | (#40498053)

That describes pretty much every scrum retrospective I've been a part of.

Re:No micro manages or quotes with NO TPS reports (5, Interesting)

ShanghaiBill (739463) | about 2 years ago | (#40497825)

There are productive meetings and there are not so productive meetings.

  • Most meetings should involve two people. Sometimes three. Rarely more.
  • Any meeting that involves more than three people should be done standing up.
  • Anyone should feel free to excuse themselves from a meeting when they feel their presence is no longer useful.
  • Meetings should have a written agenda and a clear purpose
  • Meetings should have a clearly stated start time and a clearly stated end time. Never wait for late people.
  • Meetings should have a designated note taker, and any decisions should be documented and disseminated.
  • Most regularly scheduled "status" meetings are a waste of time

Re:No micro manages or quotes with NO TPS reports (2)

Korin43 (881732) | about 2 years ago | (#40497601)

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,


all those things a boss and other employees can communicate to each other when they don't have time.

Email + Instant messenger


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:No micro manages or quotes with NO TPS reports (1)

fluffythedestroyer (2586259) | about 2 years ago | (#40497737)

Email could be a good thing but in my experience since I'm working in a big office emails are easy to lose track. Lots of people don't read emails or don't take time to read them efficiently unfortunately. Also, some people might say that "Well i emailed you that meeting review so if you didn't read it it's your fault". That might be very true but the end results are the same, they didn't read the email so theres lots of potential important info that might be lost. IMO, just try emails like you said and if it works, stick with it but if it doesn't change quicky.

Re:No micro manages or quotes with NO TPS reports (2)

Yetihehe (971185) | about 2 years ago | (#40497761)

Email + Instant messenger


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 (1)

ajcoon (964283) | about 2 years ago | (#40497819)

Fast responses == more interruptions/context switches. That's horrible for productivity, quality, and creativity.

Depends on your goals (5, Insightful)

Green Salad (705185) | about 2 years ago | (#40497199)

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 (4, Insightful)

perpenso (1613749) | about 2 years ago | (#40497951)

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.

I Can Tell You What NOT To Do... (5, Interesting)

ilikenwf (1139495) | about 2 years ago | (#40497219)

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.

Re:I Can Tell You What NOT To Do... (-1)

Anonymous Coward | about 2 years ago | (#40497349)

> I ended up having to wait 2-4 weeks for my paychecks sometimes..

Demanding to get paid in full and on time is unrealistic. I've worked as a programmer most of the past forty years for more than a dozen of the Fortune 500, and other than a few tiny companies I don't think any paid on time. Some, like a certain large company in Redmond, took months worth of calling and threatening to get a check out of them. Instead what you should do is plan ahead knowing that the tech guys always get screwed. Save enough so when, for example, someone doesn't pay you for 18 months that you have enough in your bank account to be able to afford to keep paying rent and buying food. The type of people that get promoted within companies don't understand technology so they fear it. They're always paranoid and think they're getting ripped-off so you have to fight against their natural irrationa fear in order to maybe get paid. That's why, for example, owners of companies that would never consider paying a janitor or low-level CS person late have no problem ripping off a programmer.

Re:I Can Tell You What NOT To Do... (3, Insightful)

mwvdlee (775178) | about 2 years ago | (#40497455)

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... (1)

ilikenwf (1139495) | about 2 years ago | (#40498065)

Indeed. Further, it seemed like any time we asked to be paid so we could keep our own freaking lights, internet, power, etc going at home the boss would act like we were hurting the company by doing so. He wanted us to work for free and like it instead of do good work and get paid for it - I was one of the few who cared, and we all ended up leaving, getting the axe, or otherwise getting screwed.

Re:I Can Tell You What NOT To Do... (0)

Anonymous Coward | about 2 years ago | (#40498063)

I ended up having to wait 2-4 weeks for my paychecks sometimes,

First time that happens, you leave. Nothing good ever comes out of employers like that, and you WILL end up being ripped off.

  If they don't have the business skill to manage their cash flow, they don't have the business skill to market a successful product.

Stay away from agile (5, Interesting)

Anonymous Coward | about 2 years ago | (#40497229)

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 (3, Interesting)

HeckRuler (1369601) | about 2 years ago | (#40497503)

In general it's a bad sign if your boss/peers lecture/bitch more about what process to use than how to do whatever it is you're there to do.

Re:Stay away from agile (5, Insightful)

Anonymous Coward | about 2 years ago | (#40497593)

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 ... (4, Insightful)

perpenso (1613749) | about 2 years ago | (#40497599)

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.

Re:Agile is just the latest buzz word ... (0)

Anonymous Coward | about 2 years ago | (#40497645)

The more I gain experience, the more I realize that one size does not fit all. Be flexible and be very mindful of what your goals are. Come up with a solution that meets those goals, even if it doesn't match something you've done before.

Re:Stay away from agile (4, Insightful)

gl4ss (559668) | about 2 years ago | (#40497981)

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:Stay away from agile (0)

Anonymous Coward | about 2 years ago | (#40498183)

If you know more that 50% of what you are talking about then you are not doing true Agile.

Joel (2, Informative)

perry64 (1324755) | about 2 years ago | (#40497249)

Read everything you can by Joel Spoelsky. []

Re:Joel (0)

Anonymous Coward | about 2 years ago | (#40497329)

Fuck that MS loving shit-ass.

Re:Joel (1)

HeckRuler (1369601) | about 2 years ago | (#40497517)

Yeah, he's kind of an MS-whore, but he's got nice bite-sized pieces of good information. Generally he's over-rated, but he's not a bad read.

Re:Joel (0)

Anonymous Coward | about 2 years ago | (#40497521)

TIP never hero worship anyone, especially someone imparting business advice. Because every circumstance is different, so you don't want to say "this is what The Author said should be done".

Google (1)

Anonymous Coward | about 2 years ago | (#40497259)

Use the Google/academia method that includes giving them 20% of their work time to purse their own projects

Beware the Agile/Scrum Zealots (5, Informative)

Anonymous Coward | about 2 years ago | (#40497267)

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).

kegs (1)

Anonymous Coward | about 2 years ago | (#40497271)

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

Easy (0)

Anonymous Coward | about 2 years ago | (#40497303)

A Geek office, google's style company, not much bureaucracy. You could take a friday afternoon every two weeks (by the end of the sprint) to play some games (billiards, poker, ps3, basketball, whatever the team like) and have a happy hour. Also give $$ bonus by the end of the year, or something like that and dont be evil.

A good team is tops; materialism is irrelevant. (3, Insightful)

MrCrassic (994046) | about 2 years ago | (#40497323)

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!

It might be different for different people, but... (5, Insightful)

Xiver (13712) | about 2 years ago | (#40497325)

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.

ideas and what your boss knows (3)

fluffythedestroyer (2586259) | about 2 years ago | (#40497327)

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.

Re:ideas and what your boss knows (3)

fluffythedestroyer (2586259) | about 2 years ago | (#40497375)

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, if your boss clients wants to work with java but you don't know it and lets say (not saying thats the situation right now) the market is beginning to demand it then you might start working on java.

Tips (4, Insightful)

parallel_prankster (1455313) | about 2 years ago | (#40497343)

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.

Re:Tips (5, Insightful)

dkleinsc (563838) | about 2 years ago | (#40497809)

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 (4, Insightful)

excelblue (739986) | about 2 years ago | (#40497373)

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 (2)

Anonymous Coward | about 2 years ago | (#40497379)

* 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.

Re:my thoughts (0)

Anonymous Coward | about 2 years ago | (#40498225)

* 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.

This has caused more trouble on the projects on which I've worked than any other issue.

If you are working by yourself, and your work doesn't impact anyone else's work, this may be fine. But every time I've had to deal with a coworker who liked to work in the middle of the night, he ended up causing the entire rest of the team to waste hours and even days because he screwed something up at 3AM, and couldn't be reached to fix it while the "normals" on the team were trying to work during normal business hours.

The "night owls" also tend not to make themselves available for mentoring (and it always seems to be the lone-wolf, senior guys who do this), which is a problem for the whole team. Of course, that's probably part of the reason they do what they do: They can't be bothered with all of the parts of developing software other than the coding. It may make their life more pleasant, but it hurts the team.

Lack of "methodology" (2, Interesting)

Anonymous Coward | about 2 years ago | (#40497405)

You know, the kind of "methodologies" that managers use to feel important and sophisticated. []

Intellectual honesty (5, Insightful)

rastoboy29 (807168) | about 2 years ago | (#40497413)

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.

Re:Intellectual honesty (1)

Anonymous Coward | about 2 years ago | (#40497475)

Yes, I wholly agree! Add to that, being genuinely thankful when a team member finds or fixed your bug... even if it's a hardware engineer or sales guy. A lot of trust, respect for everyone's skills, and transparency goes a long way.

Re:Intellectual honesty (5, Funny)

period3 (94751) | about 2 years ago | (#40497649)

Agree with most of this - but I would also add variable width fonts to the list.

Re:Intellectual honesty (1)

blue_teeth (83171) | about 2 years ago | (#40498095)

When money & timelines are involved, intellectual honesty wanes.

Or to put it more clearly, there is an inverse relationship with money+timelines and intellectual honesty.

Re:Intellectual honesty (0)

Anonymous Coward | about 2 years ago | (#40498113)

right on the money ... I would only make explicit something that i think is intrinsic to intelectual honesty - eliminate EGO from the equation
- no team member is better than another - everyone has something of value to offer - if they don't then they don't belong there.

Play Games (1)

second_coming (2014346) | about 2 years ago | (#40497451)

Play multiplayer games at work in scheduled sessions, great for team bonding and de-stressing.

Re:Play Games (2)

HeckRuler (1369601) | about 2 years ago | (#40497559)

Remember citizen, fun in mandatory!

MacBooks (-1, Offtopic)

0racle (667029) | about 2 years ago | (#40497453)

Everyone needs MacBooks. Pros or Airs, that doesn't matter but you must use MacBooks. All the cool developers use MacBooks. It doesn't matter what you're working on, MacBooks make it happen like 20% cooler. And that's all that matters.

Re:MacBooks (0)

Anonymous Coward | about 2 years ago | (#40497609)

Macbook is the best UNIX laptop on the market. You got a problem with that? Run along back to your litle c# shit, kid, and don't comment further on the professionals.

Re:MacBooks (0)

Anonymous Coward | about 2 years ago | (#40497657)

For about 95% of workplaces, this would guarantee all useful work would come crashing to a standstill. Definitely good for destressing, unless you're management.

a few tips (1, Funny)

Anonymous Coward | about 2 years ago | (#40497481)

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.

Add New Ideas Gradually (1)

glassware (195317) | about 2 years ago | (#40497513)

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.

Good people = good environment (4, Interesting)

Anonymous Coward | about 2 years ago | (#40497515)

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.

It depends... (0)

CSHARP123 (904951) | about 2 years ago | (#40497553)

For me, everything is developed in-house, does not care if project is delayed, manger encourages rewrite of the entire project when a newer version of the tool is released and lastly but not least they pay developers boat load of money and do not have to work more than 8 hours and don't have to support if it fails in the production.

Transparency, Flexibility, Openness, Speed (5, Insightful)

TheSpoom (715771) | about 2 years ago | (#40497569)

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 (4, Funny)

ThogScully (589935) | about 2 years ago | (#40497611)

readily available supply of Nerf weapons

Re:Nerf (1)

Bespoke (1421741) | about 2 years ago | (#40497751)

And a plentiful supply of Cheetos and Red Bull for refreshment after the epic battles?

For me its.. (0)

Anonymous Coward | about 2 years ago | (#40497629)

An atmosphere where asking questions is not just tolerated but encouraged. One where people share information (no private knowledge bases, yeah you know the type)

But most importantly one that has at least one female developer, the guys hygiene tends to improve if there is.

asking about improving morale ? (0)

Anonymous Coward | about 2 years ago | (#40497631)

this sounds like what you're asking about rather than some by the book factory process to write code. if so, then just let people work at the times that's most productive to them -- forcing someone to work from time x to y when they can't concentrate properly gives you nothing. **focus on results**and not on the clock. the same goes for "process" -- people have been looking for that "magical process" that will make humans crank out code like factory robots -- get over it already ... no such thing, stop looking. finally, there is no substitute for a good architect -- you can find tons of kids to code, but finding a good architect to cover all the angles is a lot harder. some architects double as project mgr as the devs are really building their design ... no different than a building architect overseeing the construction workers.

More old people (4, Insightful)

ljw1004 (764174) | about 2 years ago | (#40497633)

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 (3, Informative)

Iwanowitch (993961) | about 2 years ago | (#40497637)

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.

Good Read (1)

Anonymous Coward | about 2 years ago | (#40497643)

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.

Nothing beats.. (1)

nanospook (521118) | about 2 years ago | (#40497647)

Good afternoon sex! with your babe boss..

Good & Bad (1)

Nemesisghost (1720424) | about 2 years ago | (#40497653)

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.

Hire the Best (2)

shawnhcorey (1315781) | about 2 years ago | (#40497663)

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.

less plastic (0)

Anonymous Coward | about 2 years ago | (#40497665)

Plant a garden.

Continuing Education (2)

kotaro24 (465271) | about 2 years ago | (#40497675)

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... (2, Interesting)

Anonymous Coward | about 2 years ago | (#40497679)

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.

Pay well (1)

proslack (797189) | about 2 years ago | (#40497689)

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.

Depends. Under 30? Here ya go. (0)

Anonymous Coward | about 2 years ago | (#40497693)

Competition. At that age you're all ego and energy. Use it for Good.

Compete on the best, least buggy and fastest code - of course meeting specs to 'T'.

...six people developing applications for mobile devices (Android & iOS).

A LOT of potential there: Who can get it done fastestest. Who can be the most bug free.

Teasing is of course a necessity. Crappy iOs Code? You get the Rainbow "FAG" sticker.

Got chicks on the team? Fine, chicks against dicks.

Sure, your HR people will squirm (even more of an incentive!) but you'll get shit done and believe me, the chicks will kick your ass and they will cheat - if they start showing up in tight jeans and low cut T-shirts, it means you got them by the balls ... you know what I mean.

Here's the CON: unless you're on some sort of profit sharing or in on the IPO, all of your hard work will be for not. Trust me. I've been there. I was promised many things to get me to work myself to death. And I did. And here I am, out of work on posting on Slashdot durign prime business hours.

I had no life; no social life; I was lonely; It took me until 40 to find a woman to marry (too late to start a family);my friends were work friends - project/company over? so are my friends - we scattered across the World; and I have all the issues of all work and no play - all of them.)

Read Felix Dennis for a how to on destroying your life for money.

That is all. Socio-paths have created our work system.

Management (2)

Hal_Porter (817932) | about 2 years ago | (#40497697)

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 (4, Interesting)

evil_aaronm (671521) | about 2 years ago | (#40497705)

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, Git... (2, Informative)

Anonymous Coward | about 2 years ago | (#40497743)

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.

Re:Avoid UML, unit testing, instant messaging, Git (0)

Anonymous Coward | about 2 years ago | (#40497873)

Wow, git is a fad? I did not know that.

When we first started using git we wanted something for version control. After we started using we found that the way we were working had changed and slowly realized it was a development tool and not just about version control. Unlike subversion (what we switched from) it was behind the scenes for us and not "in the way."

If you are seriously proposing that distributing version systems are a fad and we are going to go back to the bad old days of svn and cvs then you need to get a refill on your prescriptions.

As for instant messaging, I hate it too, but it is harder to avoid then the phone.

The rest can go, though. :-)

Hire Older, wiser people (1)

Anonymous Coward | about 2 years ago | (#40497747)

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.

Successful Teams (1)

Anonymous Coward | about 2 years ago | (#40497765)

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.

No Comment (0)

Anonymous Coward | about 2 years ago | (#40497827)

None at all.

Hey ho let's Go! (0)

Anonymous Coward | about 2 years ago | (#40497843)

Drugs, Sex and Rock 'n' Roll!!


4 days of unrestricted time (0)

Anonymous Coward | about 2 years ago | (#40497853)

There was one company a while back that did something interesting. Once per quarter the company literally gave all employees a free day to do anything they wanted, anywhere they wanted. Working anywhere was allowed such as the beach, park, even at home. Bug fixes, catch up on old stuff, new features, etc. There were some limitations such as don't completely use up all the company resources. In exchange for this free day, the employee must show the company whatever they created/built/etc. Basically a free day to develop without any negative comments and almost no oversight. Innovative ideas flew freely unlike other places with rigid company policies.

Deming (4, Insightful)

PJ6 (1151747) | about 2 years ago | (#40497857)

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.

Good developers (1)

sl4shd0rk (755837) | about 2 years ago | (#40497923)

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.

Easy (1)

spiffmastercow (1001386) | about 2 years ago | (#40497931)

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.

Quality breeds happiness (1)

Anonymous Coward | about 2 years ago | (#40498019)

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.

culture (1)

Kogun (170504) | about 2 years ago | (#40498167)

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:

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.)

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.

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 the suggestions above is good. Food traditions are the cornerstone of cultures and that is part of our wiring. We learn to trust one another by eating shared food. Food prep is ritualistic, so when possible, rely on each other to make food or acquire food. Making a lunch for all, on site with everyone involved will do more to bond the tribe than anything else, but such a thing may not be possible at your facility. So do what you can to approximate that.

Responsibilty not blame (0)

EmperorOfCanada (1332175) | about 2 years ago | (#40498181)

It is critical to understand the difference between responsibility and blame. Most MBA run development shops are big on figuring out who to blame and handing out bonuses, promotions, probation based upon it. The best shops make sure that if you broke it then you fix it. It is a great learning experience to have to fix it in that you both learn what you did wrong and to me more careful next time. (Fixing it means working with the sysadmin to restore the backups of uncorrupted data or whatnot) By removing the blame culture you also remove much of the need for titles like product manager, project manager, architect, and so on. It just a bunch of guys who know what they are doing working together building something cool. Then you only need a supreme court in the form of an owner or one boss who resolves disputes.

This all breaks down if you have troublemakers or incompetents. The troublemakers often come in the form of highly certified my way or the highway types and the incompetents should probably just not be developers.

A sure sign of dysfunction is if some formulaic style is imposed that sounds good to MBA types but otherwise sounds stupid. Think about who would hire a Six-Sigma-Blackbelt: someone with an MBA or someone with 10 years of successful projects under their belt?

hacker time (1)

blackfrancis75 (911664) | about 2 years ago | (#40498187)

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
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account