Hacker News Reader

Comment by trilila | Hacker News Reader

Don’t treat developers like bricklayers. Sack any product manager or manager that does it. This is the root of all evil, radical as it may sound. There needs to be a balance between engineering and product delivery, but too much emphasis on product delivery leads to tech debt, cutting too many corners and poor tech choices. Not to mention stress and little to no job satisfaction. Give devs some time to build something they are proud of. Good devs are in it because they love and once that love is gone the dev is gone.

View on HN

in my experience many developers want to be bricklayers (not to discount bricklaying, there's an art to it, but they're focused on the individual bricks, not the other aspects of the building). They get annoyed when they're asked to think about the bigger picture and just want to focus on the code, the architecture, and whatever is new and shiny. It is largely due to these sorts of developers that we've developed all the ritual around sprints/product owners/etc to put blinders on them because they cannot deal with deadline and thinking in terms of business value creation.

This sort of person is under-represented here on HN for obvious reasons but they represent the majority of people developing software. The opportunity to contribute more than just lines of code should be offered and encouraged, but don't be surprised at how few will be interested.

There's a ton of truth to that. A lot of people speak like everyone wants to be a 10x engineer. Personally, being that sort of engineer has never appealed to me, and the majority of developers in my social circle in practice want to be the "bricklayers" of code because it's already a sweet financial deal.

I am one of these happy bricklayers. It's the only way I can stay sane in a job. When I'm working on my own projects, I'm all in, and I love all aspects of the process. But in a job, on a project that 99% of the time is run badly, and my colleagues are writing terrible code, just give me the bricks and tell me what to build. If I try to care, I get frustrated and depressed.

Plus, I'd be fooling myself if I were not like this. I've seen people put their passion into a job, argue their case, and then they get made redundant. Don't be fooled.

P.s. I'm a very good, reliable bricklayer who makes very solid walls.

Yeah I agree with this. If you are not in a high-up position you will just get too frustrated caring about the bigger picture because you have little power when it comes to actually making bigger-picture decisions. So all you can do is suggest things which 1) may not be well received, could be perceived as some low-level employee overstepping their bounds 2) probably won't be heeded since then the managers/pms/directors/etc. have to concede power

This is both true and hard to deal with, because sometimes these bricklayers will a) assume everyone is trying to be a bricklayer, and b) will actively attack non-bricklayers because of the perception that they're being made to look bad.

I honestly don't yet know how to fit everyone together.

> I honestly don't yet know how to fit everyone together

Bricklayers should be managed and never put into more senior role. Also, you should never build a mixed team with bricklayers and "other" developers (except for case where there is only one "other" developer and they are the team lead).

It's entirely possible their current job is done at their maximum effort without burning themselves out. So asking them for more isn't going to do anything long-term.

"The opportunity to contribute more than just lines of code should be offered and encouraged, but don't be surprised at how few will be interested."

I learned a long ago:

1) I can offer the best ideas that go beyond lines of code, but it usually comes down to the decision of someone in a higher position than me (manager, sales, the CEO, etc) and if they just don't feel like utilizing your ideas, they won't. Fighting this is more trouble than it's worth.

2) Most companies, unless you are in a startup where you wear many hats, don't want you offering your ideas. They have the ideas and want the developer to make them into a reality.

3) Most of the time, a project manager is the person that thinks about the bigger picture. I don't really want to have the responsibility of both roles..without the salary increase that comes along with it.

I love thinking about the bigger picture, which is why I have my own company I'm building on the side. But I would much rather just get my job done as a developer for my day job.

There's no shortage of ideas, especially within a company. If you want your ideas to win out, you should take advantage of what you do best… making things.

If you combine your idea pitch with a working prototype (doesn't need to be polished), it's odds of getting adopted will be far more likely.

If your idea isn't one that can be prototyped, e.g. "Ask Microsoft for a billion dollars", then you may as well just pitch it, just like anyone else.

Just out of curiosity, when would you think these prototypes should be best built? Surely not on my free time, right?

If the company is not interested on listening to new ideas, and you're keen on participating in something you would like to help build, then perhaps this is not the right company for you.

I have a project right now that I am thinking of building a prototype for on my own time and pitching to my company, because the company will basically have to sell the idea to another business. Why would I do this? Because then I can say how much I want to be compensated for my idea getting the company new business.

I honestly wish you all the best, and hope that works for you.

Just please be aware that after you've delivered, you loose power for negotiation. Therefore I would probably rethink the timeline choosen for agreeing on a reward "then I can say how much I want to be compensated for..".

I certainly do not intend to deliver anything that works before asking for compensation, I intend to show something that works and then negotiate how much it is worth.

Maybe on your free time, yes.

But only if you think it will demonstrate enough value to get you something you desire: cool work, a promotion, etc.

This requires a good understanding of what your managers and the larger organization will value, and whether they reward people who show they can deliver on those items. People's careers _do_ get bumped from these kinds of efforts, but I've seen a lot of engineers spend 40 hours prototyping something that management just won't value.

"If you combine your idea pitch with a working prototype (doesn't need to be polished), it's odds of getting adopted will be far more likely."

I have a family and only have so much free time. Even if I didn't, why would I spend my free time building anything for a company and not get compensated for it?

Even if you go through all of this, there is no guarantee you will get the responsibility and pay increase.

I honestly don't really care about any of my ideas winning out. I'm perfectly content getting told what needs to be completed and coming up with a good solution.

> They get annoyed when they're asked to think about the bigger picture and just want to focus on the code, the architecture, and whatever is new and shiny.

Maybe I'm the exception here, but this does not really describe most devs I've worked with. I've seen really smart devs just not care to argue anymore in workplaces where no one listens to them, but this is not the same thing as wanting to be a "bricklayer". Most devs usually have a lot of work on their plate and not enough time or energy to argue with some product owner or manager who is determined to get their way and who does have the time and authority to force their ideas through. On multiple occasions I've seen great teams destroyed when some determined micromanager gets promoted and decides they are going to "fix everything" without actually listening to their people with the most hands on experience. This and many other forms of organizational BS can lead to developer apathy from what I've seen, but I really don't think the dev who just wants to be a bricklayer is the norm.

I've had some conversations with managers and everyone agrees it's `employee mentality` that kills it for everyone; devs are a fickle bunch and although we all may agree in spirit to the words above, I doubt you'd actually gain any consensus as to what the words mean per se

I'd say the weak link across the board is the notion of corporacy and what it means, as well as what professional work ought to look like

fresh-faced devs straight out of university or college believe it's similar to their academic life, you get an assignment, you turn it in, you get graded cue morpheus meme: what if I told you professional life is nothing like university life?

similarly, we can't discount the international landscape of contractors and jumped-up leadership types we have to deal with, once again everyone has different ideas about what work looks like and it ranges from factory work to academic research to everything in between

A while back a bunch of consummate craftsmen worth very little in practice ruined the party for everyone with their pedantry in terms of technical concerns and set off a series of chain reactions that has quite disempowered all technology professionals

unless you're willing to revisit all your assumptions from the ground up, you'll be having this conversation again and again until you're an old coder in diapers tethered to a laptop on a walker

But that's exactly the kind of employee that most businesses want: interchangeable bricklayers.

I get that getting good developers and facilitating good code requires incentives, but this is usually at odds with the perspective of business owners, which is that employees are both a liability and an asset. Lousy developers are (seemingly) low-liability and good assets because they can make it work for cheap and, if something goes wrong in the future because of all the spaghetti code, that's when you can hire the good developers to come clean up the mess.

The truth is spaghetti works better for the ever changing requirement. After awhile the product gets rewritten.

IMO this is extremely false

Clean code is most valuable in the fact that you can add new features without old ones breaking

You should be able to write clean code from the start without it ever being classified as spaghetti as long as you stick to principles like Law of Demeter, SOLID, etc

I deal (and compete) with smart but professionally mediocre programmers (and hardware designers). Their knowledge is usually limited, but they get 80% of the job done and the customer need is addressed.

Only when the product gets used in a non-typical way or in non-typical circumstances, do the (inevitable) bugs appear. They didn't think their design choices through or they didn't know the limitations of the tool used.

So bugs are considered a known risk, and are managed. Hardware, for example, is swapped under guarantee. The most ugly bugs are fixed, and others are too costly and wait until a redesign.

But the employer likes their qualities: - he gets a mostly rapid schedule, - he gets an employee that doesn't get lost in abstractions, and - he gets to charge the customer again for the next major iteration

Basically they get him an MVP, and the customer keeps paying for each design iteration. We all know how important that is to the bottom line. To him Quality is optional, like benefits are to a job: they end up being important, but the salary usually comes first.

> But that's exactly the kind of employee that most businesses want: interchangeable bricklayers.

That's what they want... until their needs change.

I did a contract at a company where I was the test automation guy. The dev team didn't want to right tests, and they were happy to convert requirements thrown over wall A into the code the threw over wall B. The QA team caught the wall B code, and threw their results over wall D. Things took forever, but everyone was happy... until pressure to ship faster started to come down from the top.

To speed things up, they hired me to automate all the things. Well, the dev team weren't interested in helping me learn anything, and the dev manager even told me to my face that he wouldn't ass test coverage unless management asked him to & gave him extra time to make that happen. The QA team weren't coders, and they didn't really have any incentive to help me make things go faster. The build & release guy wasn't interested in getting tests integrated into the Rube Goldberg of a process that he managed.

They were all great bricklayers who told themselves they were agile because they had 1 week sprints, daily stand ups, and a all sorts of other processes. But when taking forever was no longer good enough, instead of trying to grow with it, they resisted & fought it. My role was pretty miserable, and I quit after a few months. On my way out the door, I learned that I was like the 5th person to walk, and they were planning on seeking interchangeable bricklayer #6.

In my experience, companies want interchangeable bricklayers, but they usually don't usually like the results of what they asked for.

> but they usually don't usually like the results of what they asked for.

We're not allowed to say it work because someone thought it was a race thing but... 'pay peanuts, get monkeys'

That's a totally broken culture / machine. Unfortunately, they're out there.

Oh man, I read the article, and I really identify with what you also say: I'm now in a position where I'm pretty good at my job, and my employer is keen to give me a permanent position.

And yet, whilst it's fun to be able to answer questions on the spot, regarding my area of expertise, I'm looking forward to learning more.

Now, I learnt a lot on this job, and it's very challenging on a daily basis, but it's becoming repetitive, and having talk to management, they could not tell me how they see me/my position evolving in the next 6 months/1 year/2 years. And that makes me longing for another job...

Is your manager willing to talk about knowledge transfer of some of your duties to other people? That's a double win, because they get some growth, and you get free time to pursue other interests. And if there is nothing, then at least you feel less guilty about leaving.

Your boss has revealed they have no opinions on your growth options. Do you have any ideas of your own? Offer them up.

That's a fair suggestion, thanks! Retrospectively, it might well be that I haven't been so vocal, so they might think it's all fine.

I'll think about what you said, make a list and bring it to the table next time.

Reply on news.ycombinator.com