6 ms·

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

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.

dpeck 7y ago
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.
- ravenstine 7y ago
  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.
- yezanotherone 7y ago
  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.
  - opportune 7y ago
    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
- diminoten 7y ago
  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.
  - babuskov 7y ago
    > 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).
- 0xDEFC0DE 7y ago
  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.
- cheeky78 7y ago
  "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.
  - jonny_eh 7y ago
    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.
    - vmateixeira 7y ago
      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.
      - bryanrasmussen 7y ago
        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.
- jm__87 7y ago
  > 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.
ravenstine 7y ago
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.
- wolco 7y ago
  The truth is spaghetti works better for the ever changing requirement. After awhile the product gets rewritten.
  - johnsimer 7y ago
    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
    - childintime 7y ago
      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.
artsyca 7y ago
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
cydanil 7y ago
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...
- hinkley 7y ago
  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.
  - cydanil 7y ago
    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.

dpeck 7y ago

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.

ravenstine 7y ago
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.
yezanotherone 7y ago
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.
- opportune 7y ago
  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
diminoten 7y ago
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.
- babuskov 7y ago
  > 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).
0xDEFC0DE 7y ago
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.
cheeky78 7y ago
"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.
- jonny_eh 7y ago
  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.
  - vmateixeira 7y ago
    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.
    - bryanrasmussen 7y ago
      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.
jm__87 7y ago
> 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.

ravenstine 7y ago

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.

wolco 7y ago
The truth is spaghetti works better for the ever changing requirement. After awhile the product gets rewritten.
- johnsimer 7y ago
  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
  - childintime 7y ago
    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.

artsyca 7y ago

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

cydanil 7y ago

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

hinkley 7y ago
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.
- cydanil 7y ago
  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.