{{ searchResult.published_at | date:'d MMMM yyyy' }}

Loading ...
Loading ...

Enter a search term such as “mobile analytics” or browse our content using the filters above.

No_results

That’s not only a poor Scrabble score but we also couldn’t find any results matching “”.
Check your spelling or try broadening your search.

Logo_distressed

Sorry about this, there is a problem with our search at the moment.
Please try again later.

In cities like San Francisco and New York, developers are living large. The latest internet boom has produced a new crop of billion-dollar internet giants and countless startups.

But outside of the hottest markets, the notion that developers are often grumpy and difficult to work with is still common.

Needless to say, most developers are normal people (read: not chemically imbalanced) and the bedside manner of any given developer is probably just as variable as any other professional.

But that doesn't mean that there aren't grumpy developers, and as anyone who has been involved in the development of a complex website knows, software development can be a trying endeavor fraught with sources of potential frustration, particularly on the part of those who are ultimately responsible for doing the building -- developers.

If you're fortunate enough to be working with a skilled developer, but detect a hint of grumpiness from time to time, here are six ways you can turn your frown upside down.

1. Establish scope

Many development projects turn sour because of scope issues. Scope creep, not surprisingly, is a common developer complaint and one of the most frustrating things that developers deal with.

The challenge for many clients, particularly those who aren't technical, is that specifying the functionality that needs to be developed in specific enough terms to be meaningful to a developer can be difficult and/or time-consuming. But not making the effort is more often than not more likely to produce a grumpy developer than a stellar deliverable.

2. Develop a project plan

The old adage "failing to plan is planning to fail" is particularly true when it comes to development projects. What's more: not having a project plan that identifies milestones and delivery dates can eventually lead to unhealthy tensions between you and your developer.

3. Educate yourself

Working with a developer can be an intimating thing for a non-developer, particularly if development is unfamiliar territory, but don't make the mistake of believing that acting hapless will make your developer happier or friendlier. For many developers, clients that don't know what they don't know and don't seem to care about what they know they don't know are a huge pet peeve.

While you don't have to learn the intricacies of object-oriented programming or how to design a relational database, having enough knowledge to engage in a meaningful conversation about the work you're asking your developer to perform can go a long way towards boosting a developer's morale.

4. Set expectations

There are more than a few ways to ruin a developer's day. From expanding the scope a project due to insufficient scoping to last-minute deadline changes, many developer frustrations revolve around expectations, or more appropriately, lack of expectations.

The good news: by making a concerted effort to set expectations before implementation kicks off, your developer will have far fewer reasons to be an unhappy camper.

5. Avoid micromanagement

The stereotype of developers as a largely anti-social group that prefers to be left alone in a basement may be just that -- a stereotype -- but that doesn't mean that it's a good idea to suffocate your developers either.

In many cases, micromanagement is the result of discomfort and uncertainty on the part of managers and clients. Is my developer building what's needed? How are things coming along? When you don't know the answers to these types of questions, you're far more likely to micromanage, which is why establishing scope, developing a project plan, educating yourself and setting expectations are so important.

6. Say thanks

Showing appreciation for a job well done is always a good practice, and while a truly grumpy developer may not say "you're welcome" in return, that doesn't mean that the gesture wasn't recognized.

Patricio Robles

Published 2 November, 2012 by Patricio Robles

Patricio Robles is a tech reporter at Econsultancy. Follow him on Twitter.

2394 more posts from this author

Comments (27)

Comment
No-profile-pic
Save or Cancel
Philip Storey

Philip Storey, Founder & Managing Director at EnchantSmall Business

I would add that providing them with the best possible software and tools is important, particularly for in-house developers where sometimes, senior management don't understand the importance of providing developers (and designers), with the latest kit.

almost 4 years ago

Margaret Robertson

Margaret Robertson, European Marketing Director at Canvas HolidaysSmall Business Multi-user

This is an interesting note,but very much from a developer perspective. I completely agree that for projects to be successful you need to invest time in scoping the project and clarifying the objectives, involving the developer at this stage if possible. But as a client I might switch some of your peeve points around, and ask that developers understand that business needs evolve often over the course of a project, and that most clients are answerable to multiple stakeholders. Enlightened client companies are looking to deliver the best solution for their customers,and need developers to support these objectives. Sure, we will educate ourselves - but you guys are subject matter experts & some iteration in design is inevitable and often desirable.
And on point 5 - micromanagment - totally agree this is not a good basis for a relationship but sometimes developers are not so good at communicating what they are working on,what stage they are at and how it will work from a user perspective.
In a nutshell it's like all good business relationships requiring a combo of open dialogue , respect for each other's strengths and good communication.

almost 4 years ago

Avatar-blank-50x50

Brian

My first thought was beer or video games. That's what's worked, in my experience.

almost 4 years ago

Stuart Ayling

Stuart Ayling, Founder and Director at Marketing Nous

I'm with Margaret. She hit the nail on the head from a 'client' perspective. Developers - like any subject matter expert - must learn to be effective communicators if they want to keep clients happy and make progress in their career. Otherwise the grumpy developers may appear to clients the same as arrogant lawyers. And that's not good.

As for the title of this post, I could be provocative and ask why can't developers be responsible for making themselves less grumpy?

almost 4 years ago

Stuart McMillan

Stuart McMillan, Deputy Head of Ecommerce at Schuh

Stuart, I've been a senior developer and am now a 'client', so I feel qualified to comment. I think to ask “why can’t developers just be less grumpy” is really just missing the point. One of the important things to keep in mind is that we all have different personalities which make us more or less suitable for certain jobs. Your typical developer is an introvert, has an organised mind and likes things to be planned and predictable. They're pretty much hard-wired that way. The point of this article was to talk about what we (as non-developers) can do to work better with developers, yet you seem to just want the developers to change; couldn't you meet them somewhere in the middle, in the spirit of getting the job done?

almost 4 years ago

Avatar-blank-50x50

Colin PReston

And above all, pander to them as much as possible and write articles on how to keep them happy.

almost 4 years ago

Avatar-blank-50x50

Peter Drakes, Business Analyst at Session Digital Ltd

This made me chuckle, as we are an ecommerce agency that is made up significantly of developers - my role as a Business Analyst is actually to provide specific requirements for developers and the team from the clients - actually for the opposite reasons as stated here.

We are a service agency, and bill on time worked - our guys always try to gold-plate everything, make it the best it can be, often when the client is unwilling to pay for that extra..

I would say that really though 3-6 apply to any industry and, for the most part are common sense. Only 1 & 2 apply to software development, to which I am referring my comments.

almost 4 years ago

Margaret Robertson

Margaret Robertson, European Marketing Director at Canvas HolidaysSmall Business Multi-user

Stuart
I think the original article was designed to open debate with its grumpy developers angle- but my view remains the same it is not about developers v clients but about communication and mutual respect,as in business you do have to sometimes adapt your own 'wiring' to succeed. In my experience developers come in many hues, but those who get the best results are the ones who are flexible and listen,but who also explain what they are trying to achieve and give realsitic timings outcomes - in short, work in a partnership way. Likewise we as clients have to be as supportive as we can providing the structure and direction, and hopefully sticking to the plan.

almost 4 years ago

Stuart Ayling

Stuart Ayling, Founder and Director at Marketing Nous

Yes Margaret, it's good to see debate has opened up. I work a lot with technical types who embody the introvert, planned and predictable style described by Stuart McMillan. And I appreciate different types make the world go round. As Peter noted most points could apply to any technically-oriented industry, so the situation working with developers maybe isn't that much different to other 'experts'. I suppose kudos should go to Patricio for crafting a headline and perspective that generates response.
PS. Stuart M. I didn't really mean to advocate being inflexible. My question was tongue in cheek.

almost 4 years ago

Avatar-blank-50x50

Deri Jones, CEO at SciVisum.co.uk

Yes, developers have different strengths to Marketers and etc!

Does any one here use StrengthFinders tool across their teams - great way to increase respect between teams, and team members, that have different strengths.

A great tool to reduce the specific friction with dev teams - is a well managed Agile software dev process.

This puts the onus on the business teams to do #1 above - in terms of documenting the _User Stories_ desired.

And with frequent Agile cycles - 2 week or 3 weeks say; gives fast feedback, and each time the business decide what User Stories go to the top of the list.

almost 4 years ago

Avatar-blank-50x50

Chris Jolley

Train them.

almost 4 years ago

Avatar-blank-50x50

Deri Jones, CEO at SciVisum.co.uk

Chris

Surely you are missing Stuart's point:
> Your typical developer is an introvert, has an organised mind and likes things to be planned and predictable.

The success you will have (on average) to train software devs to have the comms skills of a marketer - will be as small as the success you'd have trying to train marketers to be programmers!

I'm picking up a bit of an anti-developer vibe on this thread...

It's pretty common too at many of the eComm teams I work with - it is after all hard to find a common language - but building the bridges is important for the long term success of an eComm team.

At the end of the day guys, everything we want to achieve online is achieved through software and technology.

Everything!

So it's up to us to understand and put in place processes that work for the tech guys too.

almost 4 years ago

Margaret Robertson

Margaret Robertson, European Marketing Director at Canvas HolidaysSmall Business Multi-user

Chris - I have to disagree that everything we want to achieve online is achieved through software and technology - what about the humans ? !!
Am hoping you have tongue firmly in cheek. Certainly no anti developer sentiment on my part, I was just a bit wary of us thiking that developers are such a special breed - that they need handling with kid gloves. We all have to work with subject matter experts who are different to ourselves from time to time( e.g. finance teams, designers, etc ) and need to understand how to get the best from everyone but this should be reciprocal.
I think you do developers a disservice by pigeonholing them all into the introverted geek box.

almost 4 years ago

Avatar-blank-50x50

Peter Drakes, Business Analyst at Session Digital Ltd

@Deri I don't see what a book on Strengths finding has to do with Agile - namely creating user stories.. The way it reads it sounds like you are suggesting a link?

A Business Analyst owns the requirements and is the bridge between business values and the development team - this role could also be done by a project manager, product manager, product owner or a senior developer (and often, without formally 'knowing' or acknowledging it, is).

The IIBA lists all these roles as 'anyone who performs business analyst techniques', which could also be @Margaret as she raises a simliar point about communication. (I am a BA and not from a development background, FYI).

There has always been a dichotomy between the business values of software development and those who build it - hence roles like mine.

Initially I was infuriated at this article and its headline, giving such a dated view of developers and software development (assuming the point was made to incite debate, and wasn't formed from ignorance), however from some of the comments I am not sure if this is still how people in the ecommerce industry perceive developers, which is why for the most part things are implemented so badly...

almost 4 years ago

Avatar-blank-50x50

Peter Drakes, Business Analyst at Session Digital Ltd

P.S. Developers are humans too...

P.P.S It is for the organisation and people within it to work together, not for any one section or group to do things differently - just seem Margarets last comment, absolutely spot on.

almost 4 years ago

Avatar-blank-50x50

Deri Jones, CEO at SciVisum.co.uk

Margaret

I think it was me you were replying to, not Chris.

> I have to disagree that everything we want to achieve online is achieved through software and technology - what about the humans ?

I'm not denying the humans at all.
But for eCommerce and social media: technology is right there underpinning everything. In a way that was not quite so direct in the pre-Internet days: where the stores work even if the computers are down.

So all the clever plans and campaigns we humans create - are all delivered by technology.

> I was just a bit wary of us thiking that developers are such a special breed - that they need handling with kid gloves.

Kid gloves you're right, is not the aim.

But it is entirely sensible to understand that everyone is different, and that different strengths tend to be found in teams doing different things.

One strength you want from developers is huge attention to detail - as software will be full of bugs if brackets and commas and dots and words are not used precisely right! Whereas many marketing roles don't need that strength, they need others.

> I think you do developers a disservice by pigeonholing them all into the introverted geek box.

It's a stereotype and generalisation, and of course some dev guys have strengths in assertiveness and communication and etc.

But on average - managers and marketers will be continually disappointed if they expect dev guys to be 'like us'; so it's good practise to ensure our processes don't require dev guys to have strengths they mostly don't have.

almost 4 years ago

Avatar-blank-50x50

Deri Jones, CEO at SciVisum.co.uk

Peter

> I don't see what a book on Strengths finding has to do with Agile - namely creating user stories..

Sorry - my bad - there is no link.

> A Business Analyst owns the requirements and is the bridge between business values and the development team

Yeah, in Agile, the aim is if possible to have the actual user there. Developing software is so open ended - it;s easy for little assumptions to have huge impacts.

So the role of the middle-man Analyst is kind of problematic.

I've seen some scenarios where the IT team had a Liaison person who dealt with the Business Analyst on behalf of the actual users. Too many middle men; and success rarely happens!

> ...how people in the ecommerce industry perceive developers, which is why for the most part things are implemented so badly...

Agile is a great process because it also gets the users closer to the devs - some define User Storys (written by the business/user) as a 'committent to have a conversation'.

Having that conversation round the table is great for knocking down preconceptions of what developers are or do.

It's like getting F1 racing drivers together with their mechanics: the two have quite different strengths and talk different jargons: but can quite happily discuss the latest User Story to 'reduce steering isues on RH bends when tyres are low' - the drive can't expect the engineers to just know what he wants, or 'do the obvious' to improve something. He has to write the Story and then have the conversation.

almost 4 years ago

Avatar-blank-50x50

Deri Jones, CEO at SciVisum.co.uk

Peter

> It is for the organisation and people within it to work together, not for any one section or group to do things differently

What does 'do things differently' mean there?

almost 4 years ago

Avatar-blank-50x50

Deri Jones, CEO at SciVisum.co.uk

For the record - my view is not that dev guys are better or worse than marketers.

Just that they have, on average, different strengths to the ones we usually find in say marketers, which are different on average to the ones we find (actively look for) in say staff we hire from creative agencies.

almost 4 years ago

Heather Taylor

Heather Taylor, Editorial Director at Econsultancy

As an extension of this post, Patricio has written one for the developers on 6 ways to make your nightmare client less nightmarish : http://econsultancy.com/us/blog/11036-six-ways-to-make-your-nightmare-client-less-nightmarish

Are those points true? Any you would add?

almost 4 years ago

Avatar-blank-50x50

Anton Koekmoer

Hi Patricio,

Awesome post – As I work in an IT department and yes, Will be sending the post along to a couple of people, as they tend to have quite a couple of Grumpy developers and designers in the last couple of weeks – which they never where before. Thanks for sharing.

almost 4 years ago

Avatar-blank-50x50

Adam

I am in-house comms in a medium-sized development-led business.
I share the upstairs office space with our dev team.
They are hardcore coders, some with borderline autism-scale tendencies.
I have special fondness for them.
I find being nice to them, feeding them sweets and biscuits (or cookies for our American friends), fuelling them with tea, coffee, milkshakes and Red Bull, telling them jokes and giving them huge, uncomfortable man-on-man hugs generally keeps our relationship on track.
Also, don't mock star wars or men who live with their parents past 35 and generally everything is tickety-boo.
Dev teams are humans like me and you - only smarter.

almost 4 years ago

Stuart Ayling

Stuart Ayling, Founder and Director at Marketing Nous

@Adam Love it! That shows true understanding. And patience.

almost 4 years ago

Avatar-blank-50x50

Deri Jones, CEO at SciVisum.co.uk

Adam

that's true love. But be aware, that all those things are fine, but won't address the work things that make the dev's job harder: vaguely written User Stories; pressure put on them to 'just drop this small change in' when they are clearly saying it's not just a small change even though it may look like it.

almost 4 years ago

Avatar-blank-50x50

Adam

@Deri

True - you've got to respect the dev - but big cuddles also help.
Building a better, 'closer' working relationship with them and having a bit of a laugh means that you get a clearer understanding of what brings on the grump and how to avoid it.
It also means they cut you a little more slack when you're forced to ask for the (virtually) impossible.
Treat people like people and they'll help you out. Treat people like a resource and you're on your own.
Long live the dev.

almost 4 years ago

Avatar-blank-50x50

Deri Jones, CEO at SciVisum.co.uk

> Treat people like people and they'll help you out.

spot on Adam!

almost 4 years ago

Andy Killworth

Andy Killworth, Digital Marketing Executive at Koozai

Nice post.

I think for SEOs working with developers, both communication and expectations are key. There's often overlap between the two which is where ego can come into play and cause friction.

If both parties (and the client of course) are clear from the off who's doing what, and keep the communications channels open, then happy days.

Much easier of course when you have a design/dev company you regularly deal with. Personally I find working with 'one man bands' most tricky, especially when they think they 'know' SEO and take quite a negative attitude to implementing our suggestions.

almost 4 years ago

Comment
No-profile-pic
Save or Cancel
Daily_pulse_signup_wide

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Daily Pulse newsletter. Each weekday, you ll receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.