Comment by sonnyblarney | Hacker News Reader

Comment by sonnyblarney | Hacker News Reader

I find a lot of developers seriously lack a professional mentality (I think I'm guilty of this in my youth though I made up for it in dedication and sheer hard work.)

Moving towards the business side I hired a lot of interns from commerce/marketing and they made my devs seem like little babies, it was shocking how capable, committed, team-oriented they were. It changed my view of things.

It's a matter of culture and perspective, and of course the fact that there is definitely such a thing as 'bad management' ... but Engs do have a tendency to think they know what's best for the product roadmap, and have really strong views about all sorts of things.

Some of this is good, in a way, but I really wish somehow the culture of development could be professionalized, both in terms of general approach to working at a company - but also in terms of the artisanal aspects of development itself.

It's important to set tone and expecations early, with smaller units it might work ... but as Eng teams get big, then they always end up reporting to Eng and not product, so it really depends on the culture that the VP Eng / CTO has established.

I would say that many developers often sweat about minute technical details but completely ignore business goals. I'm involved in the local dev community and after meetups we often go for drinks. You almost never hear people talking about their company's successes, growth, strategy etc. It's all about the new hot tech they've recently had a chance to use. This mentality is reflected in the way they carry themselves and make development related decisions.

Thank you; a concise way of articulating what I had to write 10 paragraphs (below) to say.

Are developers really allowed to to think about business?

Because it's self selecting, if your more interested growth and business strategy it's unlikely you would become a developer.

> completely ignore business goals

Well, if they are not implicated in the business side of things, I don't see how they could be interested in. For example in my case, we're just getting feature requests for the next version, with no indication of business goals.

What are some specific (behavioral) examples of "lacking professional mentality"?

+ A general disregard for any activity that isn't specifically development. Like 'meetings'. Of course meetings can be overdone, but they can have a lot of value even if the topic being discussed at any moment isn't hyper-relevant to the developer himself. There's a commenter below who said he has a dev who'll bring in competitive offers if he's asked to go to more than two meetings a week for example. This dev has his 'teamwork' hat on upside down. Sometimes you need teamwork to focus on hyper specific issues. It may seem wasteful often it's not.

+ A general disregard for the talents and value of other groups. (Funniest example: 'ice cream day' at work and these devs cam to sit by us just as we were sitting down and a dev sneers: "Ugh, marketing". We just laughed.) Eng. talent is more classically academic, and yes, marketing is full of fluff, but good marketing, operations, finance is really hard. Basically an intellectual condescension that bleeds into a lot of things.

+ Failing to internalize that ultimately, they work for a business. Sometimes that means doing a lot of things an Eng would never do, like bolt-ons or weird add-ons to address specific customer needs. Cringing around metrics or optimizations that are ROI oriented and maybe not perfectly suited to their vision of what a 'good product' should be. This one can be a real problem in terms of attitude ... because they can get rally angry and stuffy. It's almost an existential debate over who really 'owns' the product in a sense - the business, or the people 'making it'? It really bothers me sometimes the cynical take that many Engineers have in this area - because the presumption is that 'they know better' or 'it's their thing' but really it's not at all. Basically, their view of 'raison d'etre' is often upside down. It depends on the organization.

+ Engs without management experience have a disrespect for how hard management actually is ... more so than in other groups. Marketing specialists are generally not like that.

+ Getting caught up in ideological wars about architecture, or 'bike shedding' - we're all guilty of this, but it's funny how ridiculous and perverse this is when you step outside of it. We're 'building something' not making some kind of 'functional art'. As techies we all love 'new toys' so this one is more understandable.

+ On the business side, if I ask staffers to get something figured out, to give me a quick analysis, to make some slides for the Veep, if they are good, they'll nail it down and move forward. On the dev side, if they even move to it, I get a lot of academic prose as though they don't know the language of business.

It's almost as though it's a little existential: so many on the business side play on 'sports teams' etc. are are very extroverted and team oriented, confident, and natural communicators. Often devs are not. So there's almost a natural cultural clash as well.

You don't have to strongly convince or persuade team players. They don't have tidbits of antagonism, or 'special needs'. They show up early, bang stuff out, realize that the world is somewhat political, that nothing is perfect, that we have to bend for customers, we do 'what needs to be done'.

Edit: hugely generalizing here. Everyone and every team is different.

Re-reading it I make it seems like devs are this terrible bunch! Not at all, most of this is subtle, it's nuanced, it's not like we have gross dereliction, just some different patterns of culture and behaviour.

I think many of these issues are caused by a "silo" mentality. Decisions often flow from the business end through product before finally ending up as a story in the developers backlog.

How can the devs understand the business decisions and learn to make less academic slides if they are not exposed to the business?

I worked at a medium sized business where devs had lunch with sales/product/marketing and was treated as more than just coders. That has helped me a lot when it comes to the business side of work.

If you have problems with the developers in your company, it may be that the real problem is with the company culture.

I agree with your points about exposure - however - these problems generally do not exist in other parts of organizations.

Devs are unique in their peculiar aspect disdain for 'management and business'.

And unfortunately it's very rare that devs get such exposure but we agree it'd be great if they could.

Have you considered that the disdain comes from not being treated with respect?

I don't know what comes first.

But the places where engineers get on well with management are the ones where their opinions matter. Otherwise resentment comes in.

Devs are unique but I would argue it's less of the dev mentality and more about how management and business can incorporate them as part of the decision-making process.

Granted technical folk are a special breed but being technical myself and having moved over to the business side of things, it's still equally important to think about motivation for devs.

To maintain engagement, I bring my technical guys with me to meetings where they can add value. And I always press about the value of meetings and what we're trying to get out of it.

"...You don't have to strongly convince or persuade team players. They don't have tidbits of antagonism, or 'special needs'.

Yeah, and this is exactly the kind of person that gets laid off first. You have to be a little bit of an asshole to survive. Have an "edge", even if it works against the company, so you are perceived as a "badass".

Being a dev myself I 100% agree with this.

I think this can also depend a lot on whom you hire. If you make that a screening criterion, it’s not all that difficult to assemble an engineering team entirely of people who understand business goals, can communicate with non-technical types, and recognize the value of other fields and departments.

Your list resonates with me on all points. Sadly, it seems that due to scarcity in the market some engineers are acting like self entitled, spoiled babies. The arrogant/know-it-all streak on topics way outside their area is also pretty pervasive. It changes with age though. I was like this 10 years ago to some degree. You mellow out over the years.

I think that you make a lot of very good points. I have also seen self-entitled, arrogant developers stomping around like they own the place, not respecting the difficulties in different roles (management) or other disciplines. I've seen endless bike-shedding, and endless toy-chasing (at the direct expense of the business).

But I also think that there are some significant problems in what you've said.

You describe what looks like a siloed structure, where sales/marketing people are deciding on what to build, and then throwing it over the fence to the developers to just "get on with". Where are the fast iterations, looping frequently back to the customer, and involving the whole team in the process? Does a developer never have a good idea with regards to features? I think that if you want robots who do what exactly they're told, then you're going to end up with... a development staff of robots.

Meetings. Endless meetings. Agile, if done on a weekly cycle, gives you no fewer than seven mandatory meetings. I don't disagree that it's important to communicate, but the prevailing culture across the industry is absolutely towards superfluous meetings which involve too many people. And I think that's a big problem. Yes, developers need to understand that perhaps not all of a meeting will be relevant to them, but if they're not relevant to the meeting, then really they shouldn't be in it.

"Failing to internalize that ultimately, they work for a business." - I think that the above point on solied structures is relevant here, but I think that there is more also. It depends on the type of business, and I think that you're referring to B2B. But I have personally seen in the B2C case, with millions of users, the sales and marketing side - sometimes from different divisions - preference their own career objectives over the user's experience. "We sold this for a million dollars" "But there's spyware on the partner side sometimes" "Tough. Build the integration". So while I think that you're right when it comes to building a special-case for a particular customer who genuinely needs that special case, I think that there are also other cases here where it's not that simple.

A more minor point but when you say "as though they don't know the language of business", I think you're right, they don't know the language of business!

I find your sports team / jocks vs nerds analogy interesting, perhaps mostly to inform on your general perspective. Personally I would prefer a team of smart developers who care deeply about the product that they build, working hand-in-hand with the product team, designers, sales, and customer in short iterations where rather than deciding precisely what will be built up-front, the solution is instead found organically with valuable contributions from everyone.

But you're dead right on the 'new toys'. That practice is unforgivable.

Reply on news.ycombinator.com