Forgot your password?
typodupeerror
Businesses Programming Software Technology

Ask Slashdot: What Defines Good Developer Culture? 239

Posted by Soulskill
from the dim-lighting-and-shorts-in-winter dept.
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."
This discussion has been archived. No new comments can be posted.

Ask Slashdot: What Defines Good Developer Culture?

Comments Filter:
  • culture? (Score:5, Funny)

    by masternerdguy (2468142) on Friday June 29, 2012 @02:23PM (#40497083)
    Soon we'll be using rasberry pis bought with bitcoins in the year of the linux desktop.
    • Re: (Score:2, Funny)

      by Anonymous Coward

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

    • Re:culture? (Score:5, Insightful)

      by Darinbob (1142669) on Friday June 29, 2012 @03:54PM (#40498355)

      I know this is a joke, but seriously what the hell is "developer culture"? There seems to have been this bizarre and nonsensical fad with HR groups about developing corporate culture recently. They'll talk about what their culture is and try to foster it and all sorts of feel good fuzzy things, without even acknowledging that every building and every part of the buildings will have teams that act differently. The only times "culture" seems to make sense is with describing dysfunctional companies where some people don't fit in with the in-crowd and are excluded. I've seen kids complain that the companies they've applied to don't have a good "culture" and whine that they're expected to do unreasonable things like show up on time and get the job done.

      Only culture I've ever really seen in real life is that building A has the group that goes out and gets wasted every thursday, building B has Hawaiian shirt fridays, building C has the IT guys who stick to themselves.

      You definititely do NOT want homogeneous culture. If you have a goofy guy with all the toys you do not want that in every single cube. You don't want the guy with the tie in every single cube. You don't want everyone to be the same age, race, or gender. You don't want developer culture to be hippie dippie stuff like everyone has to sit around and brainstorm for 2 hours on tuesday, or have stand up meetings, or to give daily reports. You just want people who can do their jobs and interact with others. (I'd suggest not doing agile either but I see the OP has drunk that koolaid already)

      • Re:culture? (Score:5, Funny)

        by Gripp (1969738) on Friday June 29, 2012 @04:41PM (#40499031)
        meh... prior to my current job i would have agreed with you 100%. But I've actually stumbled into working somewhere that actually does have a culture. Everyone here is willing to put in as much time as it takes to make our clients happy; including staying up until 4am for a load test one night and then waking at 3am for a meeting with an overseas client the next. We've had people hop on and help troubleshoot while at the hospital and vacation, and drive hardware to other states over their weekend. More importantly, there is never a boss forcing or even asking it to be done, we just do what we know is needed. Co workers are open to receiving and dishing out honest opinions - no matter how harsh - and build stronger relationships with other on the count of it.

        It may sound gruesome, but that is where the company embracing culture and its employees comes in. While we are semi expected to be in the office between 10am and 6pm, there is no one watching or caring what time you leave or come in - so long as you're getting your job done. Hell, we don't even track time! Any given night there is at least a few of us out having drinks, and even working from the bar. And more importantly, we are all very accepting. Anyone busting their asses is welcome, with open arms. Our office has a full service coffee bar with a barrista (free), free soda, free snacks, ping pong tables, several arcade machines, a theater and buys lunch for everyone every friday. We have no internet filters or people watching our activity. it's not all that uncommon to see people on facebook or reddit or even playing a video game. It's not uncommon for nerf gun fights to break out, or coworkers facebook bombing each other. Again, all that matters is performance. We all recognize that some weeks are 80 hours of chasing fires, and others are spent dicking around. Working from home is accepted, so long as it isn't abused. And even then they deal with it on an individual basis rather the typical all-encompassing "new company rules" approach. There are no "designated smoke breaks" and no one bitching about the smokers (myself being one have been previously unaccustomed to not constantly hearing that crap). Internal meetings are full of cursing - with our CEO being the biggest potty mouth. In fact, we make it a point to drop as many 4 letter words as we can during interviews to make sure the candidate isn't uptight about that kind of thing.

        This may sound like an impossible environment to work/be productive in... but our flagship product has over 30 million lines of code, we have a hosted environment with 5 datacenters globally + EC2 overflow + PCI walled gardens, and hundreds of premise clients as well - all of which we support 24/7 without discrimination or cost to the client. And since our product is the backbone of many solutions, we have to deal with nearly every type of language and tech out there. python, ruby, groovy, java, C, php, opa, ccxml, vxml, html, groovy, js/jquery, etc. Even better, the purpose of our product is to parse/render many of those languages, it requirs a fairly deep understanding of them, and constant learning... we have to work with ALL db's, OS's, web service types, packet analysis, working with various carriers and telco's and hardwares, etc. . All done with around 100 employees, total - which only about 60 are technical.

        TL;DR - free/happy employees make the best employees. Just make sure you focus on hiring/keeping the aces.
        • 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)

        by composer777 (175489) * on Friday June 29, 2012 @08:00PM (#40500821)

        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)

          by Glonoinha (587375) on Friday June 29, 2012 @09:05PM (#40501159) Journal

          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.

        • by b4dc0d3r (1268512)

          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

  • Do I need to tell you I'm joking?
  • by TheNinjaroach (878876) on Friday June 29, 2012 @02:28PM (#40497147)
    An emphasis on keeping high-quality & intelligent developers. Don't ever let intellectually lazy developers onto your team.
    • by DrVomact (726065) on Friday June 29, 2012 @02:34PM (#40497241) Journal

      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.

    • by sinan (10073)

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

    • Re: (Score:2, Funny)

      by alphatel (1450715) *

      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.

    • "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

    • by perpenso (1613749) on Friday June 29, 2012 @03:35PM (#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.
    • by Tough Love (215404) on Friday June 29, 2012 @03:40PM (#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

    Let people do work with out all the BS meetings and paper work.

    • by fluffythedestroyer (2586259) on Friday June 29, 2012 @02:36PM (#40497265) Homepage
      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.
      • 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.

        • by seepho (1959226) on Friday June 29, 2012 @02:52PM (#40497493)
          The solution is obvious: have a meeting to discuss the usefulness of meetings.
        • by ShanghaiBill (739463) on Friday June 29, 2012 @03:15PM (#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
          • by Darinbob (1142669) on Friday June 29, 2012 @04:02PM (#40498461)

            No standing up! First that gets really close to agism. Some people say only 5 minutes max but it won't happen, some doofus will keep talking. Standing up as a goal to keep meetings short will not work, it will just make people feel uncomfortable and fidgety. The only reason to have one is if your company is too poor to buy chairs and the carpet is too dirty to sit on.

            If you excuse yourself when you no longer feel useful, no meeting would ever last more than 30 seconds.

          • by geekoid (135745)

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

            by Anonymous Coward

            • 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

            Oh man! Hahaha! Whoosh on me! I laughed pretty hard when I finally realized that everyone was actually talking about sex.

      • by Korin43 (881732)

        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)

        • by Yetihehe (971185)

          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.

  • by Green Salad (705185) on Friday June 29, 2012 @02:32PM (#40497199) Homepage

    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.

    • by perpenso (1613749) on Friday June 29, 2012 @03:23PM (#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.
    • by PCM2 (4486)

      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

    • by oakbox (414095)

      +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,

  • by ilikenwf (1139495) on Friday June 29, 2012 @02:33PM (#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.
    • by mwvdlee (775178) on Friday June 29, 2012 @02:49PM (#40497455) Homepage

      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.

  • Stay away from agile (Score:5, Interesting)

    by Anonymous Coward on Friday June 29, 2012 @02:33PM (#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.

    • by HeckRuler (1369601) on Friday June 29, 2012 @02:52PM (#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.
      • by pspahn (1175617)

        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

        • You bitch to the boss. Note that I was talking about when YOUR boss or PEERS bitch. When an underling is bitching about the process, you should listen. Dealing with overambitious design guys is his job, even when it makes more work for you.

          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.
    • by Anonymous Coward on Friday June 29, 2012 @02:59PM (#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!"

    • by perpenso (1613749) on Friday June 29, 2012 @02:59PM (#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.
    • by gl4ss (559668) on Friday June 29, 2012 @03:25PM (#40497981) Homepage Journal

      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.

    • by Eil (82413) on Friday June 29, 2012 @04:10PM (#40498579) Homepage Journal

      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.

    • by S77IM (1371931)

      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)

    by perry64 (1324755)
    Read everything you can by Joel Spoelsky.

    http://www.joelonsoftware.com/ [joelonsoftware.com]
  • by Anonymous Coward on Friday June 29, 2012 @02:36PM (#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).

  • 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!
  • by Xiver (13712) on Friday June 29, 2012 @02:40PM (#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.
  • by fluffythedestroyer (2586259) on Friday June 29, 2012 @02:40PM (#40497327) Homepage
    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.
    • 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)

    by parallel_prankster (1455313) on Friday June 29, 2012 @02:41PM (#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 (Score:5, Insightful)

      by dkleinsc (563838) on Friday June 29, 2012 @03:14PM (#40497809) Homepage

      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)

    by excelblue (739986) on Friday June 29, 2012 @02:43PM (#40497373) Homepage

    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.

  • by Anonymous Coward

    * 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

  • by Anonymous Coward

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

    http://programming-motherfucker.com/ [programmin...fucker.com]

  • by rastoboy29 (807168) on Friday June 29, 2012 @02:46PM (#40497413) Homepage
    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.
  • 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

  • by Anonymous Coward on Friday June 29, 2012 @02:53PM (#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.

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

    by ThogScully (589935) <neilsd@neilschelly.com> on Friday June 29, 2012 @03:00PM (#40497611) Homepage

    readily available supply of Nerf weapons

  • More old people (Score:5, Insightful)

    by ljw1004 (764174) on Friday June 29, 2012 @03:01PM (#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.

  • by Iwanowitch (993961) on Friday June 29, 2012 @03:02PM (#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 afternoon sex! with your babe boss..
  • 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

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

  • by Anonymous Coward

    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

    • There's good culture and bad culture. Every place has it's own. Enthusiastic startups, monolithic corporates, brogrammers, 9-5 time-card punchers, TPS reporters, associates of synergizing proactive meetings to co-align the group's baseline throughput, these are all describing different types of cultures. And yes, they simply form on their own. Sometimes that'll mean every commit has derogatory statements about the sanctity of marriage. There are code-shops where the culture allows and/or encourages that sor
  • 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.
  • 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)

    by evil_aaronm (671521) on Friday June 29, 2012 @03:06PM (#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.
  • by Anonymous Coward

    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

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

    by PJ6 (1151747) on Friday June 29, 2012 @03:17PM (#40497857)
    I recommend you read up on what this guy [wikipedia.org] had to say about operations and engineering.

    You may find many of his ideas surprisingly applicable to software development.
  • People with a real affinity for inventing and building things with code seem to work out pretty well. An innate curiosity about how other people do things, and why, is something to look for too. On the teamwork part, it works best if you can find someone who is able to listen to other people's perspectives. Time and again we get people in the door who look great on paper but cannot work effectively with other people. If you keep someone like that staffed, it eventually sinks the boat. Oh -- immediately pa

  • 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.
  • the #1 thing in my view is to have a period set aside, so that Developers can work on/learn/develop something new, which may or may not be directly applicable to the project at hand. - it should (preferably) at least have some relationship to software development - it doesn't have to be a lot of time - even say an hour a week, or one Friday afternoon a month. At Google, employees get 20% of their time to work on whatever they want. - the developer has to report back his findings to the rest of the group
  • motivated people.

  • 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

  • "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,

  • 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

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

  • by tlambert (566799) on Friday June 29, 2012 @04:30PM (#40498861)

    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)

    by Anonymous Coward

    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.

  • by mbkennel (97636) on Friday June 29, 2012 @04:40PM (#40499005)

    *) Don't turn your workplace into a fraternity.
    *) a super-automatic espresso machine, and pay for all the coffee & maintenance of said machine.
    *) Agree that you don't want to do anything stupid or wasteful even if some book, or person, think's its the 'best practice' or 'cool'
    *) newer is not always better. Newer is not always worse.

  • 1 Any time you start hearing tocatta and fugue in d minor make sure you start getting supplies to comp for the extra stress on your team (Snax and Soft Drinks for the team would be a start)

    2 make sure that marketing does not OverSell The Product

    3 if you have Married Team Members you may want to setup some sort of OnSite Daycare (this is a MUST if you have Female Married Team Members) even if this is a spare conference room with an On Call caretaker.

    4 treat your employees like people not like Droids (unless

  • 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

  • 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

You can measure a programmer's perspective by noting his attitude on the continuing viability of FORTRAN. -- Alan Perlis

Working...