Heisenberg Developers (2014)(mikehadlow.blogspot.cl)
mikehadlow.blogspot.cl
Heisenberg Developers (2014)
http://mikehadlow.blogspot.cl/2014/06/heisenberg-developers.html
192 comments
The success/failure of a project hinges on lots of things. Amongst them, code quality, which heavily dictates your reactivity.
Having a technically-blind management isn't going to work, especially if it leads to policies like "no refactoring" or "no time for tests".
Another thing: high-tech is an innovation-driven market. Most of the ideas are going to come from your developers, so why adopt a management style killing their creativity?
Another thing: high-tech is an innovation-driven market. Most of the ideas are going to come from your developers, so why adopt a management style killing their creativity?
> Having a technically-blind management isn't going to work, especially if it leads to policies like "no refactoring" or "no time for tests".
That's the entire idea of technical debt. It's just like real debt, only that it's cost is development time. And it takes time to pay it down. The only difference is that it's not reported on a balance sheet, so management doesn't care about it.
That's the entire idea of technical debt. It's just like real debt, only that it's cost is development time. And it takes time to pay it down. The only difference is that it's not reported on a balance sheet, so management doesn't care about it.
It's their codebase, they paid for it. If they don't want to maintain it properly, then it's on them. It will just get more and more expensive to maintain until they replace it with newer technology.
Developers fetishize their codebases and complain about unpaid technical debt, but not all the bad code I've run across I can push off to management making the wrong decisions. I've seen a lot of bad decisions made by the original developer too, who just did things improperly.
Devs have this nasty tendency to push their mistakes onto their employer by calling it technical debt. If you're incurring technical debt, then you need to spend some time analyzing it and coming to a real understanding of the tradeoffs you're making in doing it a certain way. Hopefully you'll have documentation somewhere that describes the debt, what's being worked around, and what it would take to do it right.
If you're not doing that, then you're just leaving a mess for the next guy. Messy work isn't technical debt, it's just sloppy work.
Developers fetishize their codebases and complain about unpaid technical debt, but not all the bad code I've run across I can push off to management making the wrong decisions. I've seen a lot of bad decisions made by the original developer too, who just did things improperly.
Devs have this nasty tendency to push their mistakes onto their employer by calling it technical debt. If you're incurring technical debt, then you need to spend some time analyzing it and coming to a real understanding of the tradeoffs you're making in doing it a certain way. Hopefully you'll have documentation somewhere that describes the debt, what's being worked around, and what it would take to do it right.
If you're not doing that, then you're just leaving a mess for the next guy. Messy work isn't technical debt, it's just sloppy work.
> It's their codebase, they paid for it.
> Devs have this nasty tendency to push their mistakes onto their employer by calling it technical debt.
You can't have it both ways. Either the employer owns the code and is responsible for monitoring and managing technical debt, or it's the dev's responsibility and the employer needs to make that clear and hire people who can balance decisions effectively.
> Devs have this nasty tendency to push their mistakes onto their employer by calling it technical debt.
You can't have it both ways. Either the employer owns the code and is responsible for monitoring and managing technical debt, or it's the dev's responsibility and the employer needs to make that clear and hire people who can balance decisions effectively.
> You can't have it both ways.
Sure you can. They paid for the codebase, it's theirs. You don't own it, whether you have the responsibility for keeping it maintained or not. That's true no matter which approach the company takes to managing their technical infrastructure. They can make decisions about it with or without your input and there's absolutely nothing wrong with that. It's theirs, not yours.
What you own is a responsibility to that codebase and to that company. A responsibility that the company is paying you for. It's your responsibility to not fuck up that codebase. If there are conflicts, you need to bring them up to your employer and let them make the decision.
What I think you're not getting is that tasks like cleaning up, refactoring, etc. are part of the job and that you're not doing your job properly if you don't do them. You do not bring these up to your employer or allow him to stop you from doing them, because they're part of the job.
If you work in construction, clean up is part of the job, you don't ask your boss whether you clean up or not, you clean up and he pays you for the time. Same with dev work. It's not up to them, you are a professional and nobody should tell you how to work. If they don't like it they can fire you, and you can go somewhere that appreciates your professionalism. You'll probably get paid more too.
Sure you can. They paid for the codebase, it's theirs. You don't own it, whether you have the responsibility for keeping it maintained or not. That's true no matter which approach the company takes to managing their technical infrastructure. They can make decisions about it with or without your input and there's absolutely nothing wrong with that. It's theirs, not yours.
What you own is a responsibility to that codebase and to that company. A responsibility that the company is paying you for. It's your responsibility to not fuck up that codebase. If there are conflicts, you need to bring them up to your employer and let them make the decision.
What I think you're not getting is that tasks like cleaning up, refactoring, etc. are part of the job and that you're not doing your job properly if you don't do them. You do not bring these up to your employer or allow him to stop you from doing them, because they're part of the job.
If you work in construction, clean up is part of the job, you don't ask your boss whether you clean up or not, you clean up and he pays you for the time. Same with dev work. It's not up to them, you are a professional and nobody should tell you how to work. If they don't like it they can fire you, and you can go somewhere that appreciates your professionalism. You'll probably get paid more too.
> You do not bring these up to your employer or allow him to stop you from doing them, because they're part of the job.
I agree with that. Don't need to discuss how sausage is made. OP was pointing out that there are circumstances where the sausage making is micromanaged, which puts a kink in this plan.
I agree with that. Don't need to discuss how sausage is made. OP was pointing out that there are circumstances where the sausage making is micromanaged, which puts a kink in this plan.
Wouldn't put a kink in mine. I'd just carry on as usual. When I write code, I don't release it until it's been cleaned and refactored to my satisfaction. If a micromanaging boss wants to know my progress, the answer is simple. It's not done. He wants to know why, I'll tell him. I'm not happy with X class and I'm cleaning up the methods and reorganizing it. Should only take another hour.
If he starts getting 1984 on me and demanding I cut it short and deploy, then it's time for a closed-door meeting. He might be my boss, but he's not telling me how to do my job.
If he starts getting 1984 on me and demanding I cut it short and deploy, then it's time for a closed-door meeting. He might be my boss, but he's not telling me how to do my job.
I agree with many of the points you make, I don't agree with your assignment of blame. Good developers can make bad decisions. It's just that it may not be seen for a year or two. In a SaaS platform it's hard to see around a corner a year from now.
The thing about technical debt, is that once you have accrued it, it doesn't really matter how it got there. You either accept it exists and carry the balance or fix it. And typically, it's the role of management to recognize this.
The thing about technical debt, is that once you have accrued it, it doesn't really matter how it got there. You either accept it exists and carry the balance or fix it. And typically, it's the role of management to recognize this.
"I mean, come on, in the grand scheme of things, developers are wizards who never have to be worried about 90% of the things other people in the world have to worry about."
wat
wat
Sounds like a 'you have a better than average income so you shouldn't complain about stuff'. Two problems:
1. Fiscal income is not the end all be all of determining quality of life.
2. The argument itself doesn't work; one only needs to apply it to others to see how it works. Take a poor person on welfare and tell them they don't have to worry about things that people in third world countries where welfare doesn't exist do. The whole 'how are they poor if they have refrigerators' argument. You quickly see how empty the argument is.
1. Fiscal income is not the end all be all of determining quality of life.
2. The argument itself doesn't work; one only needs to apply it to others to see how it works. Take a poor person on welfare and tell them they don't have to worry about things that people in third world countries where welfare doesn't exist do. The whole 'how are they poor if they have refrigerators' argument. You quickly see how empty the argument is.
>magic
You seem to forget that most of the best coders have spent countless hours learning a ton of things. It's not something easy or without a tax on the mental.
I found it easy enough. I learn new things for fun. I don't consider it taxing at all. Anyone who wants to pay me to learn something new, I'm happy to oblige them.
> I found it easy enough. I learn new things for fun. I don't consider it taxing at all
I have no doubts that you find learning fun and find it easy, but the last sentence I'm a little hesitant with. It reminds me of a single pane comic strip I recently saw. It was of a business man receiving a logo from a designer, and he said, "Why should I pay you $X dollars for a logo you designed in ten minutes?". To which the artist replied, "It took me ten years to get that quick at making logos." Learning the art of software development is similar, you need to get a solid foundation in your domain of knowledge before you can build anything both well and quickly or before you start to find things easier to figure out.
I would like to stress that programming is very hard and taxing when you are completely new to it and it progressively gets easier and easier. I only was recently re-informed of how hard programming is as I have recently helped my brother begin programming, because like you for the most part I find it relatively simple to learn something new. Though I find it easy to learn I notice when I first dive into a new framework, language, or codebase I do have to watch my stress levels and make sure I'm not getting overwhelmed by it.
>I mean, come on, in the grand scheme of things, developers are wizards who never have to be worried about 90% of the things other people in the world have to worry about. These finer qualities of career enjoyment are nice-to-haves, not necessities.
If by wizards you mean everything they do seems like magic to everyone who has never written any code and themselves and their methods are often misunderstood I would say that is true, and I think that may be part of the problem. Though some might oppose it I think the idea of educating more people in CS in grade schools might help combat that.
To the second sentence, I would say everyone has their own measurement of what a necessity and a nice-to-have is, but often most things people complain about aren't completely necessary. You can tell he (the blog poster) has a problem with the way things are being done at his company I appreciated his opinion although I don't necessarily take his stance.
I have no doubts that you find learning fun and find it easy, but the last sentence I'm a little hesitant with. It reminds me of a single pane comic strip I recently saw. It was of a business man receiving a logo from a designer, and he said, "Why should I pay you $X dollars for a logo you designed in ten minutes?". To which the artist replied, "It took me ten years to get that quick at making logos." Learning the art of software development is similar, you need to get a solid foundation in your domain of knowledge before you can build anything both well and quickly or before you start to find things easier to figure out.
I would like to stress that programming is very hard and taxing when you are completely new to it and it progressively gets easier and easier. I only was recently re-informed of how hard programming is as I have recently helped my brother begin programming, because like you for the most part I find it relatively simple to learn something new. Though I find it easy to learn I notice when I first dive into a new framework, language, or codebase I do have to watch my stress levels and make sure I'm not getting overwhelmed by it.
>I mean, come on, in the grand scheme of things, developers are wizards who never have to be worried about 90% of the things other people in the world have to worry about. These finer qualities of career enjoyment are nice-to-haves, not necessities.
If by wizards you mean everything they do seems like magic to everyone who has never written any code and themselves and their methods are often misunderstood I would say that is true, and I think that may be part of the problem. Though some might oppose it I think the idea of educating more people in CS in grade schools might help combat that.
To the second sentence, I would say everyone has their own measurement of what a necessity and a nice-to-have is, but often most things people complain about aren't completely necessary. You can tell he (the blog poster) has a problem with the way things are being done at his company I appreciated his opinion although I don't necessarily take his stance.
There's an art to learning. I work on that too. The better I get, the quicker it takes me to integrate new ideas.
> Learning the art of software development is similar, you need to get a solid foundation in your domain of knowledge before you can build anything both well and quickly or before you start to find things easier to figure out.
If you look at all the other skilled professions you'd find similar dynamics. You spend a lot of time paying your dues. Once you've paid them, then you have to learn how to turn them into a career. What's unfortunate about development is that there's never that moment where you call yourself done with the skill-building part and start on the career-building part. Other professions have that, but development does not and probably never will. It's too big, and changes too much for an examination to be worthwhile.
> If by wizards you mean everything they do seems like magic to everyone who has never written any code and themselves and their methods are often misunderstood I would say that is true, and I think that may be part of the problem.
That sense of magic is what keeps salaries relatively high compared to other individual contributors. It also means that we can cloister ourselves into priesthoods where those with the arcane knowledge can band together against the uneducated masses. I used to think coders needed a union, until I realized we've already pretty-well self-organized into one.
> Learning the art of software development is similar, you need to get a solid foundation in your domain of knowledge before you can build anything both well and quickly or before you start to find things easier to figure out.
If you look at all the other skilled professions you'd find similar dynamics. You spend a lot of time paying your dues. Once you've paid them, then you have to learn how to turn them into a career. What's unfortunate about development is that there's never that moment where you call yourself done with the skill-building part and start on the career-building part. Other professions have that, but development does not and probably never will. It's too big, and changes too much for an examination to be worthwhile.
> If by wizards you mean everything they do seems like magic to everyone who has never written any code and themselves and their methods are often misunderstood I would say that is true, and I think that may be part of the problem.
That sense of magic is what keeps salaries relatively high compared to other individual contributors. It also means that we can cloister ourselves into priesthoods where those with the arcane knowledge can band together against the uneducated masses. I used to think coders needed a union, until I realized we've already pretty-well self-organized into one.
I'm guessing you're new in this trade.
I envy you. Mostly being a programmer learning "new" things is the same as a taxi driver moving to a different city every half year and learn the new topology.
In both cases, you're not learning anything that is fundamental to human knowledge.
In both cases, you're not learning anything that is fundamental to human knowledge.
Well, unless you're a research scientist, nothing you ever learn is fundamental to human knowledge.
But depending on what you spend your time learning, you can improve in your craft. I think that is valuable. For some people becoming excellent craftsmen gives them purpose in life.
But depending on what you spend your time learning, you can improve in your craft. I think that is valuable. For some people becoming excellent craftsmen gives them purpose in life.
You can work backwards towards first principles. In my case, whenever I learn something new, I always stop to boil things down to the essentials. What does this new tool / framework actually do, what am I hoping to accomplish.
Then I try to work it as best I can into my current toolset. For me, all projects get a repo on Github, and I get the nasty infrastructure bits implemented first, like deployment workflow, before actually working on the problem.
There's an art and craft to learning new things that I find fulfilling all on its own without having to turn it into something lofty.
Then I try to work it as best I can into my current toolset. For me, all projects get a repo on Github, and I get the nasty infrastructure bits implemented first, like deployment workflow, before actually working on the problem.
There's an art and craft to learning new things that I find fulfilling all on its own without having to turn it into something lofty.
> The company is bigger than you are, its decisions weigh heavier than yours. Stop with the ego-belief that you know better than it.
You sound just like a church.
Friction is good, differences in opinions and priorities are good. Especially in a creative environment. When a part of that is silenced based on just organisational/hierarchical arguments, everyone involved will become less effective in one way or another.
I do agree with you that after not being able to fix the organisational problem, walking away is not the cowards path.
You sound just like a church.
Friction is good, differences in opinions and priorities are good. Especially in a creative environment. When a part of that is silenced based on just organisational/hierarchical arguments, everyone involved will become less effective in one way or another.
I do agree with you that after not being able to fix the organisational problem, walking away is not the cowards path.
As an individual contributor, your ability to fix organizational problems is limited and efforts to do so are almost inevitably plagued by wishful thinking. You're just not in a position to be able to change how people think about things. Your skillset is not with people, it's with code.
That really depends on the IC and the organization. That's probably true at some places. At a 30 person startup you'd be amazed at how much individual engineers can change things.
And here I thought I was cynical...
> Especially in a creative environment.
It is not a creative environment. We are talking about mid- to big-sized projects and companies here. Not the scrappy startup, not the open source consultant shop, not the small niche application for your Macbook.
Differences in opinions are good, provided the team as a whole is reasonably aligned. Too much divergence and this "room for creativity" becomes a schizophrenic organization.
It is not a creative environment. We are talking about mid- to big-sized projects and companies here. Not the scrappy startup, not the open source consultant shop, not the small niche application for your Macbook.
Differences in opinions are good, provided the team as a whole is reasonably aligned. Too much divergence and this "room for creativity" becomes a schizophrenic organization.
Did the development team in this example become more or less productive after it became "reasonably aligned"?
What the author describes is that the manager manipulated the consensus building in the team, by adding friends to the team so he can start ignoring them. Consensus building is a key part of any organization and doing this is not ethical.
Then, what you describe: reducing technical debt is a nice to have? life is too short to care about quality? That's pretty much, in your own words "the coward way": "checking out mentally".
Then, what you describe: reducing technical debt is a nice to have? life is too short to care about quality? That's pretty much, in your own words "the coward way": "checking out mentally".
This is almost completely wrong.
Building consensus is just one management style. It is by no means the only one, or even the only effective one. It's not unethical to manage in a different fashion. The people being managed don't like it, but that doesn't make it unethical. Just find a better job.
Checking out and doing what you're told is a rational response, one that management would not be opposed to seeing. You're still getting paid the same, but are having your responsibilities taken away. Most other people are overworked and underpaid, you're getting underworked and overpaid. So why complain?
Being able to come into work, do a job, and go home without having to be worried about the outcome of your efforts, to have someone else on the hook for it, that would be looked at by a lot of people as a luxury. But devs all seem to have this ego that keeps them from being able to appreciate the reprieve.
Yes. Check out mentally. Do your job and go home at 5 and do all those other things in your life that you've been neglecting because you were putting that energy into your job. Spend time with your wife and kids, date if you're single. Work on your hobbies. Enjoy it because that's not going to last forever either.
Building consensus is just one management style. It is by no means the only one, or even the only effective one. It's not unethical to manage in a different fashion. The people being managed don't like it, but that doesn't make it unethical. Just find a better job.
Checking out and doing what you're told is a rational response, one that management would not be opposed to seeing. You're still getting paid the same, but are having your responsibilities taken away. Most other people are overworked and underpaid, you're getting underworked and overpaid. So why complain?
Being able to come into work, do a job, and go home without having to be worried about the outcome of your efforts, to have someone else on the hook for it, that would be looked at by a lot of people as a luxury. But devs all seem to have this ego that keeps them from being able to appreciate the reprieve.
Yes. Check out mentally. Do your job and go home at 5 and do all those other things in your life that you've been neglecting because you were putting that energy into your job. Spend time with your wife and kids, date if you're single. Work on your hobbies. Enjoy it because that's not going to last forever either.
What I see from many of your comments, and why I think you're getting so much opposition, is that you are suggesting we should be satisfied simply being programmers while many people here on Hacker News want to be more than that.
The reality may be that many of us are just programmers and that the real struggle isn't with the project management but with our refusal to accept our role. I can't argue with that. We can't all be architects; someone has to lay the bricks and you can spare yourself some trouble, and even find some satisfaction, by accepting that from time to time someone will tell you to lay the bricks the other way. But I wouldn't demean people for wanting to do more.
Personally, I don't find programming very fulfilling. I don't get satisfaction from producing a sufficient quantity of code, but from solving sufficiently challenging problems. Coding a means-to-an-end for me, just a medium to express my thoughts and ideas like pen and paper to an artist. When my job became more about bullet-point features and timelines than the problems the system was supposed to solve I struggled. A lot. In fact I started looking for new problems to solve in lieu of the ones I had been working on, like why the project was struggling and how to convince the project managers they were just digging us deeper into technical debt.
Fortunately I'm being moved to another team as part of a restructuring in our organization and had the opportunity to explain my perspective to my new manager, who suggested I could be put on more of a leadership track. Will it happen? Will it be better? I don't know, but trying means I can see if my current employer wants to see what else I can offer and help me grow or if they just want me to sit down, shut up, and spit out some code.
The reality may be that many of us are just programmers and that the real struggle isn't with the project management but with our refusal to accept our role. I can't argue with that. We can't all be architects; someone has to lay the bricks and you can spare yourself some trouble, and even find some satisfaction, by accepting that from time to time someone will tell you to lay the bricks the other way. But I wouldn't demean people for wanting to do more.
Personally, I don't find programming very fulfilling. I don't get satisfaction from producing a sufficient quantity of code, but from solving sufficiently challenging problems. Coding a means-to-an-end for me, just a medium to express my thoughts and ideas like pen and paper to an artist. When my job became more about bullet-point features and timelines than the problems the system was supposed to solve I struggled. A lot. In fact I started looking for new problems to solve in lieu of the ones I had been working on, like why the project was struggling and how to convince the project managers they were just digging us deeper into technical debt.
Fortunately I'm being moved to another team as part of a restructuring in our organization and had the opportunity to explain my perspective to my new manager, who suggested I could be put on more of a leadership track. Will it happen? Will it be better? I don't know, but trying means I can see if my current employer wants to see what else I can offer and help me grow or if they just want me to sit down, shut up, and spit out some code.
> why I think you're getting so much opposition
Getting plenty of upvotes too. If I find I'm not controversial enough, I'll dig around for something more interesting to say.
> you are suggesting we should be satisfied simply being programmers
I'm doing nothing of the sort. What I'm saying is that you shouldn't let your job become your identity. Dream big, but realize that the best company to be the receptacle for those dreams is the company you build yourself. This was a hard lesson for me to learn, but ultimately it makes everybody happier; you, your SO, the company you currently work for, the people you're working with on the side.
My go-to saying for this is "Don't fall in love with something that can't love you back."
Getting plenty of upvotes too. If I find I'm not controversial enough, I'll dig around for something more interesting to say.
> you are suggesting we should be satisfied simply being programmers
I'm doing nothing of the sort. What I'm saying is that you shouldn't let your job become your identity. Dream big, but realize that the best company to be the receptacle for those dreams is the company you build yourself. This was a hard lesson for me to learn, but ultimately it makes everybody happier; you, your SO, the company you currently work for, the people you're working with on the side.
My go-to saying for this is "Don't fall in love with something that can't love you back."
Thanks for your clarifying where you're coming from. I read comments like
> All good things eventually come to an end, and you need to be ready for the inevitable.
> You're just not in a position to be able to change how people think about things. Your skillset is not with people, it's with code.
> You're still getting paid the same, but are having your responsibilities taken away. Most other people are overworked and underpaid, you're getting underworked and overpaid. So why complain?
and it sounds like 'The professional world sucks. Deal with it.'
But with a bit of context I think they can be read in a way that should resonate with more people here, perhaps 'The professional world sucks. If you think you're ready to go out and tackle that problem then get out there and do it.'
> All good things eventually come to an end, and you need to be ready for the inevitable.
> You're just not in a position to be able to change how people think about things. Your skillset is not with people, it's with code.
> You're still getting paid the same, but are having your responsibilities taken away. Most other people are overworked and underpaid, you're getting underworked and overpaid. So why complain?
and it sounds like 'The professional world sucks. Deal with it.'
But with a bit of context I think they can be read in a way that should resonate with more people here, perhaps 'The professional world sucks. If you think you're ready to go out and tackle that problem then get out there and do it.'
I'm not interested in resonating. I want to challenge people's beliefs. I don't care for platitudes. I want to dive down into the subtleties and tease out complex truths.
I don't think the professional world sucks. I think it's awesome. I spent much of my twenties doing construction work. That world sucks. The professional world sucks only so long as you lack professionalism.
Once you learn professionalism then the professional world stops being able to hold you. I have been Office Space-ing my work life down to where I can do pretty much whatever I want with my work time.
I have been cultivating business contacts for some time now, creating a network of clients so that I can make my jump into the business world. The professionalism you learn in corporate jobs is invaluable there.
Every day brings with it a more relaxed approach, more return on my efforts, more ease in learning new things.
Developers are missing out on the unique opportunities that the professional world offers by focusing on non-issues like whether their bosses will allow them to pay down technical debt. How utterly silly from my perspective! If it's that important to you, just man up and do it, damn the consequences!
I don't think the professional world sucks. I think it's awesome. I spent much of my twenties doing construction work. That world sucks. The professional world sucks only so long as you lack professionalism.
Once you learn professionalism then the professional world stops being able to hold you. I have been Office Space-ing my work life down to where I can do pretty much whatever I want with my work time.
I have been cultivating business contacts for some time now, creating a network of clients so that I can make my jump into the business world. The professionalism you learn in corporate jobs is invaluable there.
Every day brings with it a more relaxed approach, more return on my efforts, more ease in learning new things.
Developers are missing out on the unique opportunities that the professional world offers by focusing on non-issues like whether their bosses will allow them to pay down technical debt. How utterly silly from my perspective! If it's that important to you, just man up and do it, damn the consequences!
Let's face it, you are going to spend the majority of your life at work. Is money the only thing you care about? If so, why not doing something else? Nobody gets rich being a checked out employee.
You not only get paid with money, you get also paid with experience. That experience has a market value.
If your resume reads: "mindless checked out employee in tyrannic sweatshop using 15 years old tech", your market value will be lower than "engaged employee in innovative company using cutting edge tech". So if money matters to you, you should care about investing your career in experiences that lead to a higher market value.
You not only get paid with money, you get also paid with experience. That experience has a market value.
If your resume reads: "mindless checked out employee in tyrannic sweatshop using 15 years old tech", your market value will be lower than "engaged employee in innovative company using cutting edge tech". So if money matters to you, you should care about investing your career in experiences that lead to a higher market value.
It seems to me that checking out mentally is only an option if you're doing mindless, repetitive work. But as Fred Brooks put it, "The programmer, like the poet, works only slightly removed from pure thought-stuff." So is it even possible for programmers to check out mentally without seriously degrading the quality of their work?
> "The programmer, like the poet, works only slightly removed from pure thought-stuff."
I don't agree with this. Programming does not start from scratch. You are always building on someone else's work. Sure, there's the hardware and software you're building on top of, but there's also methodologies and philosophies that other people came up with that you're using too, even if it's only subconscious. It's not the same all-encompassing mental marathon that writing good poetry is. Or, at least, it doesn't have to be.
My work quality went up when I stopped caring about things I really shouldn't have been caring about. I now feel that the biggest source of problems in codebases comes not from so-called technical debt, but from programmers incessantly biting off more than they can chew.
I don't agree with this. Programming does not start from scratch. You are always building on someone else's work. Sure, there's the hardware and software you're building on top of, but there's also methodologies and philosophies that other people came up with that you're using too, even if it's only subconscious. It's not the same all-encompassing mental marathon that writing good poetry is. Or, at least, it doesn't have to be.
My work quality went up when I stopped caring about things I really shouldn't have been caring about. I now feel that the biggest source of problems in codebases comes not from so-called technical debt, but from programmers incessantly biting off more than they can chew.
You are assuming that staying 8 hours a day in a job you don't care about is less consuming than staying those 8 hours in a job you love.
I can't even imagine where did you get that from. One will cause deep depression and burnout in no time - the other is a wonderful life experience.
I can't even imagine where did you get that from. One will cause deep depression and burnout in no time - the other is a wonderful life experience.
I can care about doing a good job and keeping a tight ship without having to care about company politics. A job is what you make of it. As far as I'm concerned, I'm not breaking rocks apart with a hammer for 16 hours a day, and I have some bargaining power to make my lifestyle better, so why complain? I don't understand people that have to turn work into some grand quest to make the world better. I think these sorts end up making more unhappiness than they do happiness.
A job you love is a great thing. But that job is only going to last as long as the economics work, or the company wants it to last, or if you're doing the business end as well as the technical end. Once it's gone, just find another job and work out ways to love it.
A job you love is a great thing. But that job is only going to last as long as the economics work, or the company wants it to last, or if you're doing the business end as well as the technical end. Once it's gone, just find another job and work out ways to love it.
> I can care about doing a good job and keeping a tight ship without having to care about company politics.
In this case, no you can't. Company politics has placed a superior of yours explicitly tasked into order you to do a bad job.
I do completely agree with the "just find another job" line. What I don't agree is with that "cheer, your job is less stressing now".
In this case, no you can't. Company politics has placed a superior of yours explicitly tasked into order you to do a bad job.
I do completely agree with the "just find another job" line. What I don't agree is with that "cheer, your job is less stressing now".
Nobody can task you to do a bad job. You do that yourself. You may find excuses for doing a bad job, but you chose to do it, they didn't hold a gun to your head.
If I find that I absolutely have to either cut corners or let the deadline slip, I let the deadline slip. I refuse to knowingly release crappy work, you can fire me for it, I don't care. But long before that deadline, I will have explored the options for changing the scope of the project so such a decision isn't necessary.
"Just find another job" isn't sufficient because every job involves making tradeoffs between personal goals and business goals. I believe in being real clear with management about what's happening so that we can work towards an equitable solution.
If I find that I absolutely have to either cut corners or let the deadline slip, I let the deadline slip. I refuse to knowingly release crappy work, you can fire me for it, I don't care. But long before that deadline, I will have explored the options for changing the scope of the project so such a decision isn't necessary.
"Just find another job" isn't sufficient because every job involves making tradeoffs between personal goals and business goals. I believe in being real clear with management about what's happening so that we can work towards an equitable solution.
[deleted]
[deleted]
The author is simply describing a transformation from a system driven mostly by intrinsic motivation to a system driven by an extrinsic one.
Typically complex tasks are solved better in an environment with emphasis on intrinsic motivators.
It's not wissful thinking. It's a keen observation.
Basically management offloads the responsibility of actually managing to a process of accounting. It's a less skillfull, less productive, but a much more predictable form of management.
The problem was not the Jira. It was the new PM who instituted the cultural change. Jira can be used just a well to document work done by intrinsic motivators.
Typically complex tasks are solved better in an environment with emphasis on intrinsic motivators.
It's not wissful thinking. It's a keen observation.
Basically management offloads the responsibility of actually managing to a process of accounting. It's a less skillfull, less productive, but a much more predictable form of management.
The problem was not the Jira. It was the new PM who instituted the cultural change. Jira can be used just a well to document work done by intrinsic motivators.
This, 100%. I agree that complex tasks are generally better solved in an environment driven by intrinsic motivation - heck, probably all tasks and not just complex tasks.
I'm not sure if Jira and other task tracking tools can be used just as well to document work done by intrinsic motivators though. I mean, yes, they _can_ be, but I don't think they're as good as they could be. In fact, I'd say there's a big gap in the market for a solution that gives non-technical managers some reassurance that progress is being made while also not getting in the way of the ad hoc workflows the post describes.
I'm not sure if Jira and other task tracking tools can be used just as well to document work done by intrinsic motivators though. I mean, yes, they _can_ be, but I don't think they're as good as they could be. In fact, I'd say there's a big gap in the market for a solution that gives non-technical managers some reassurance that progress is being made while also not getting in the way of the ad hoc workflows the post describes.
I've found that tracking tools are good to have even at times when I've been able to work in the manner of freedom the article describes. It's just that they are used differently, more in a way to help remember things. Things that either needs to be done or things that have been done. Especially those nightmarish things that took a long time to solve, so documenting the process is good for the future, in case it happens again.
It wasn't always like that for me (document, bah! comments, bah!) but as I grow older I've come to appreciate the possibility to offload information in my brain to a more persistent media. This way I only keep the index in my brain ("Hey, wait a minute, I recognize this..."). Maybe I'm just lazy but I hate doing the same thing twice. I also hate saying the same thing twice so before I explain something to someone I like to write it down and give them a copy. Then when they ask me about it I simply refer them to the document (in a friendly (RTFM) manner).
It wasn't always like that for me (document, bah! comments, bah!) but as I grow older I've come to appreciate the possibility to offload information in my brain to a more persistent media. This way I only keep the index in my brain ("Hey, wait a minute, I recognize this..."). Maybe I'm just lazy but I hate doing the same thing twice. I also hate saying the same thing twice so before I explain something to someone I like to write it down and give them a copy. Then when they ask me about it I simply refer them to the document (in a friendly (RTFM) manner).
"there's a big gap in the market for a solution that gives non-technical managers some reassurance that progress is being made"
That's not a tool gap but a trust gap in the team, and no tool can remedy that, IMO.
That's not a tool gap but a trust gap in the team, and no tool can remedy that, IMO.
The same research that shows that complex tasks are better solved with intrinsic motivation also shows that simple tasks are better solved with extrinsic motivation. That is, measuring mechanical/repetitive work does increase its productivity.
What we have today is an almost complete lack of mechanical/repetitive work to measure.
What we have today is an almost complete lack of mechanical/repetitive work to measure.
> The problem was not the Jira.
The first problem was thinking that you could set meaningful hard deadlines for inadequately defined goals. The second problem was acting as though they were meaningful.
The first problem was thinking that you could set meaningful hard deadlines for inadequately defined goals. The second problem was acting as though they were meaningful.
> The company is bigger than you are, its decisions weigh heavier than yours. Stop with the ego-belief that you know better than it. It's cold comfort to be right, so just get behind management and try to make the new direction work.
I don't want to put too fine of a point on it, but it sounds like you might have missed the point of the article. The author was saying that efforts to improve business outcomes by closely managing engineering work often have the exact opposite effect of what is intended. As you soon as you start trying to measure developers you slow them down, hence the title.
I don't think it's "ego-belief that you know better" if a business says "we want to ship things faster, let's try doing X" and you see that X actually slows things down to then say, "hey let's not do X, it actually slows things down."
The author does seem to think he knows better than anxious middle managers who are overly eager to change how things are done. But, well, I'm inclined to believe that he does.
That said, there are very real concerns and worthwhile motivations that lead managers to start closely project managing engineering. And in reality free-form engineering can lead to lots of time wasted on personal obsessions, or just plain slacking. So I agree about the rose-colored glasses.
I don't want to put too fine of a point on it, but it sounds like you might have missed the point of the article. The author was saying that efforts to improve business outcomes by closely managing engineering work often have the exact opposite effect of what is intended. As you soon as you start trying to measure developers you slow them down, hence the title.
I don't think it's "ego-belief that you know better" if a business says "we want to ship things faster, let's try doing X" and you see that X actually slows things down to then say, "hey let's not do X, it actually slows things down."
The author does seem to think he knows better than anxious middle managers who are overly eager to change how things are done. But, well, I'm inclined to believe that he does.
That said, there are very real concerns and worthwhile motivations that lead managers to start closely project managing engineering. And in reality free-form engineering can lead to lots of time wasted on personal obsessions, or just plain slacking. So I agree about the rose-colored glasses.
> I don't think it's "ego-belief that you know better" if a business says "we want to ship things faster, let's try doing X" and you see that X actually slows things down to then say, "hey let's not do X, it actually slows things down."
No, it's not. What is is when they say no and you persist in your belief. They said no for a reason, not grasping that reason or willfully ignoring it is a function of ego.
No, it's not. What is is when they say no and you persist in your belief. They said no for a reason, not grasping that reason or willfully ignoring it is a function of ego.
I'm 100% in favor of "checking out mentally". Only I describe it differently. When you start insisting on what's good for the business and your employer disagrees, there's only so far you should go, because in the end they're paying you to do what they (possibly unreasonably) want. It's okay to push back against micromanagement, but that should be viewed as a selfish struggle for better work conditions (or better pay to compensate), not a selfless struggle to make the company better.
Sure rose-colored glasses is a part of it. But at the same time, you have them too. The problem here is lack of leadership and the organization is trying to solve it with management. The parable of the loggers is apt in the authors situation.
> A group of loggers is busy chopping away doing great work under the supervision of the managers and achieving high productivity and throughput. Someone from a mountain overlooking the forests notices something and shouts "hey, you down there ..." - reply: "we are busy, and making great progress" ... and the person on the mountain yells "Wrong forest!"
I would try to leave the company, checking out mentally while waiting for the right opportunity and getting behind management helping them get the rope so they can hang themselves. Because ultimetly the company is bigger than me and if I'm not happy working there just building features why would I stay? I don't want a reputation of building buggy software, because the company I work for doesn't focus on it. The company has no loyalty to me if times are tough, because thay lay me off if times are tough. So companies shouldn't expect any loyalty to stay from me either if they take decision that are against my interests.
> A group of loggers is busy chopping away doing great work under the supervision of the managers and achieving high productivity and throughput. Someone from a mountain overlooking the forests notices something and shouts "hey, you down there ..." - reply: "we are busy, and making great progress" ... and the person on the mountain yells "Wrong forest!"
I would try to leave the company, checking out mentally while waiting for the right opportunity and getting behind management helping them get the rope so they can hang themselves. Because ultimetly the company is bigger than me and if I'm not happy working there just building features why would I stay? I don't want a reputation of building buggy software, because the company I work for doesn't focus on it. The company has no loyalty to me if times are tough, because thay lay me off if times are tough. So companies shouldn't expect any loyalty to stay from me either if they take decision that are against my interests.
> The problem here is lack of leadership and the organization is trying to solve it with management.
Management is a resource that can be easily added or subtracted from an organization, leadership is not. Good leaders are rare, but management can be taught.
Management is a resource that can be easily added or subtracted from an organization, leadership is not. Good leaders are rare, but management can be taught.
Yeah and management alone doesn't suffice. Only managing the adding features and not managing the quality is a problem, and as I see it lack of leadership.
You didn't seem to grasp my point.
Management is a resource a company can throw at a problem. Leadership is not. Positing solutions that can't be implemented is the very definition of wishful thinking. Calling it a lack of leadership isn't helpful. You need to break the problem down further and try to find a way to solve it that doesn't involve supermen.
Management is a resource a company can throw at a problem. Leadership is not. Positing solutions that can't be implemented is the very definition of wishful thinking. Calling it a lack of leadership isn't helpful. You need to break the problem down further and try to find a way to solve it that doesn't involve supermen.
The thing is that I'm only telling what the solution isn't. Solution might be, to ask the people doing the actual work the right questions. But if that is not happening or if no one is listening to the answers, the solution is for an individual to change company. Because in my experience when the shift to wrong type of management happens, it seldomly fixes itself. And as a lowly peon you can't influence enough to change a culture that isn't a good fit for yourself.
I.e. the company is ruined if you think it is. There are no solutions, you are doing the company and yourself a disservice by staying.
I.e. the company is ruined if you think it is. There are no solutions, you are doing the company and yourself a disservice by staying.
Oh, the joy of being a product manager for the particular type of programmer who, by virtue of being a programmer, also knows absolutely everything about absolutely everything.
This is the type that refuses to tell you if they think, completely ballpark, whether something will take a day or a week or a month, but if they disagree with a tiny aspect of the feature you've brought them, the deep domain knowledge you were hired for and dozens of customer visits you've done are nothing in the face of the awesome might of their computer science degree. Better get comfortable, because it's going to take you several hours to persuade them that you do in fact know how to do your job and the wild-ass alternative they've just come up with is wanted by the market about as much as syphilis.
With these guys (and they're always guys) you've got to process up and micromanage, because the only way to get a little bit of intelligent estimating out of them is to ask for ten times as much, so they can give you what you need while still feeling like they're largely ignoring you. The only silver lining is the process eventually makes them leave, so they can be replaced by people who work well with others.
You know, I really don't miss being a product manager.
Ranting aside, good developers in larger organizations realize that people have specializations, they and other parts of the company are interdependent, and a little administrative overhead is necessary to keep everybody moving forward together - so they work with people from other parts of the company in good faith, and this makes it possible to keep the administrative crap (which no one likes, it's not just them) as light as possible for as long as possible.
This is the type that refuses to tell you if they think, completely ballpark, whether something will take a day or a week or a month, but if they disagree with a tiny aspect of the feature you've brought them, the deep domain knowledge you were hired for and dozens of customer visits you've done are nothing in the face of the awesome might of their computer science degree. Better get comfortable, because it's going to take you several hours to persuade them that you do in fact know how to do your job and the wild-ass alternative they've just come up with is wanted by the market about as much as syphilis.
With these guys (and they're always guys) you've got to process up and micromanage, because the only way to get a little bit of intelligent estimating out of them is to ask for ten times as much, so they can give you what you need while still feeling like they're largely ignoring you. The only silver lining is the process eventually makes them leave, so they can be replaced by people who work well with others.
You know, I really don't miss being a product manager.
Ranting aside, good developers in larger organizations realize that people have specializations, they and other parts of the company are interdependent, and a little administrative overhead is necessary to keep everybody moving forward together - so they work with people from other parts of the company in good faith, and this makes it possible to keep the administrative crap (which no one likes, it's not just them) as light as possible for as long as possible.
> because it's going to take you several hours to persuade them that you do in fact know how to do your job
Never, ever argue about the person! When arguing with programmers you should only argue about the technical side. For them it's not about prestige, it's about making a perfect system.
Never, ever argue about the person! When arguing with programmers you should only argue about the technical side. For them it's not about prestige, it's about making a perfect system.
X+Y=3 because I know math (wrong)
X+Y=3 because X=1 and Y=2 (right)This is the type that refuses to tell you if they think, completely ballpark, whether something will take a day or a week or a month
A comment in the article made a similar point. QFT:
A comment in the article made a similar point. QFT:
I dare say you wouldn't win much work though
turning up to pitch to potential customers and
declaring that you'll definitely deliver
something, but you don't know how long it will
take or how much it will cost.
If businesses didn't make promises before they knew if they could keep them, the deadlines wouldn't be such a problem.
If an employee agrees to a deadline, it's fine. If an employee is just told they have to complete a task within a deadline that they're weren't included in estimating, that's not the employee at fault.
If an employee agrees to a deadline, it's fine. If an employee is just told they have to complete a task within a deadline that they're weren't included in estimating, that's not the employee at fault.
Thats not what gyardley is saying though. He's talking about developers who refuse to estimate how long a chunk of work will take.
An interesting point on developers who refuse to estimate, is how often they are then asked "Why ?".
I'm definitely someone who has either refused to give, or given massively exaggerated estimates in the past, for various reasons, the main being "I don't know".
Think about this for a moment - why wouldn't an (experienced) engineer know how long something will take ?
The most likely answer (and in retrospect the only reason I ever did this) was that the project was far too large / complicated to visualise, and needed to be broken down.
By asking an engineer to break the task down into smaller tasks, until they can 'ballpark' estimate each part, is the best way to solve this problem. Maybe more design or investigation will be required to manage the breakdown.
Instead of writing off 'problem' engineers, try to work with them and find the common ground.
I'm definitely someone who has either refused to give, or given massively exaggerated estimates in the past, for various reasons, the main being "I don't know".
Think about this for a moment - why wouldn't an (experienced) engineer know how long something will take ?
The most likely answer (and in retrospect the only reason I ever did this) was that the project was far too large / complicated to visualise, and needed to be broken down.
By asking an engineer to break the task down into smaller tasks, until they can 'ballpark' estimate each part, is the best way to solve this problem. Maybe more design or investigation will be required to manage the breakdown.
Instead of writing off 'problem' engineers, try to work with them and find the common ground.
Probably been bitten by estimates being treated as deadlines issue. So he just doesn't bother.
Software estimation has been proven to be extremely hard and inaccurate in many academic studies, and yet business tends to want software developers to held to those estimates.
Software estimation has been proven to be extremely hard and inaccurate in many academic studies, and yet business tends to want software developers to held to those estimates.
I think there's a middle ground here, and you're being somewhat unfair. And yes, the article writer wants a utopia that he won't often find. But his criticisms of a certain kind of company culture and bad unresponsive political management are valid
> This is the type that refuses to tell you if they think, completely ballpark, whether something will take a day or a week or a month
Software development is about figuring out how to do something. Sometimes you can still kind of estimate how much time something will take, especially if it is some grunt work. But truly meaningful changes are unestimatable. If I told you 'I want you to make me some Japanese kuhoo kuhoo. I wont tell you what it is, what goes into making it and if it is even a real thing that can be made. Now tell me how much time it will take', how can you react to that ? I am not saying you acted this way, but I have seen managers act this way.
> but if they disagree with a tiny aspect of the feature you've brought them, the deep domain knowledge you were hired for and dozens of customer visits you've done are nothing in the face of the awesome might of their computer science degree
Why not just let the developers do all these things ? We have been asking our product managers for customer visits for years. Would that be the end of the world ?
Software development is about figuring out how to do something. Sometimes you can still kind of estimate how much time something will take, especially if it is some grunt work. But truly meaningful changes are unestimatable. If I told you 'I want you to make me some Japanese kuhoo kuhoo. I wont tell you what it is, what goes into making it and if it is even a real thing that can be made. Now tell me how much time it will take', how can you react to that ? I am not saying you acted this way, but I have seen managers act this way.
> but if they disagree with a tiny aspect of the feature you've brought them, the deep domain knowledge you were hired for and dozens of customer visits you've done are nothing in the face of the awesome might of their computer science degree
Why not just let the developers do all these things ? We have been asking our product managers for customer visits for years. Would that be the end of the world ?
Ha, I usually have the opposite problem (and I'm on the other side of the table). Product guys (and they're always guys) telling me to design the thing they want me to ship, because they suck at making decisions and want someone else to do it. (Of course they phrase it differently.)
No dice, it's my job to build the thing and your job to decide what the thing is.
No dice, it's my job to build the thing and your job to decide what the thing is.
>This is the type that refuses to tell you if they think, completely ballpark, whether something will take a day or a week or a month,
I don't mind giving people an estimate if they know what the word means.
I don't mind giving people an estimate if they know what the word means.
Absolutely, sow an estimate, reap a commitment, get plowed by a deadline.
This is similar to an experience I had. Me and the small dev team were being micromanaged. But we were getting lots of new customers for version 2.0 of our main software product and specifically targetting feature relases to snag certain customers, I feel like it worked from a business perspective.
We didn't have time to refactor, didn't have time to anticipate how something would be used in the future and build extensibility into it and the number of hacks in the codebase grew daily.
most of us on the dev team knew it was going to be a complete disaster at some point. It was going to take a week to fix a simple bug because it's copy-pasted in 7 different places and something derivative now relied on the bugs behavior.
But we were releasing fast and getting money because of it. Initially we fought it but eventually I just figured that if I wasn't on another project when it came time to pay the piper then I'd just find another job.
I had given my warnings - when I did have time I still tried to do things right and refactor old code. Ultimately though, the business tradeoff decisions weren't mine to make and I wasn't going to lose any sleep over it.
We didn't have time to refactor, didn't have time to anticipate how something would be used in the future and build extensibility into it and the number of hacks in the codebase grew daily.
most of us on the dev team knew it was going to be a complete disaster at some point. It was going to take a week to fix a simple bug because it's copy-pasted in 7 different places and something derivative now relied on the bugs behavior.
But we were releasing fast and getting money because of it. Initially we fought it but eventually I just figured that if I wasn't on another project when it came time to pay the piper then I'd just find another job.
I had given my warnings - when I did have time I still tried to do things right and refactor old code. Ultimately though, the business tradeoff decisions weren't mine to make and I wasn't going to lose any sleep over it.
This is one of the best posts on software development I've read in many years. Each sentence rings true and is an amazing read.
Its like the author is describing many of the projects I've worked before.
Micromanagement and software factories are the death of software development.
But then no matter how much I dislike these management methods, I can see why they are put in place.
There are certain developers that get to a project and just start rewriting everything with no good reason, introducing new cutting edge tools and frameworks for the fun of it and for pure CV driven development.
They introduce huge bugs close to release dates, breaking browser support, refusing to test on IE.
Lets face it, loose canons exist on all teams and we've all seen it before.
This is OK and necessary in the early development cycle, but when things get to production its different. One day something gets seriously broken, and management comes in putting in JIRA or equivalent, and micromanagement starts.
Demotivation of the early developers sets in, the ones who knew how to setup an architecture and make technical decisions. The leave and are replaced by other developers that don't necessarily could take those decisions.
The project entered a pure maintenance phase, where business as sort of given up asking too many features, it just costs too much and the results are less than ideal.
The project enters the keep it running final phase, where noone knows how certain parts of the system work anymore, all original developers long gone. Here the goal is to touch the code as least as possible and its no longer a development job, its mostly technical analysis and troubleshooting of test environments.
Then 5 or 7 years have gone through, and the business decides to replace the system with a new one and the cycle starts again.
The only way i've found to deal with this, is to become a contractor and work mostly on early to mid phases of projects. When the project enters pure maintenance I wait for a few months and then look for a new project.
Its like the author is describing many of the projects I've worked before.
Micromanagement and software factories are the death of software development.
But then no matter how much I dislike these management methods, I can see why they are put in place.
There are certain developers that get to a project and just start rewriting everything with no good reason, introducing new cutting edge tools and frameworks for the fun of it and for pure CV driven development.
They introduce huge bugs close to release dates, breaking browser support, refusing to test on IE.
Lets face it, loose canons exist on all teams and we've all seen it before.
This is OK and necessary in the early development cycle, but when things get to production its different. One day something gets seriously broken, and management comes in putting in JIRA or equivalent, and micromanagement starts.
Demotivation of the early developers sets in, the ones who knew how to setup an architecture and make technical decisions. The leave and are replaced by other developers that don't necessarily could take those decisions.
The project entered a pure maintenance phase, where business as sort of given up asking too many features, it just costs too much and the results are less than ideal.
The project enters the keep it running final phase, where noone knows how certain parts of the system work anymore, all original developers long gone. Here the goal is to touch the code as least as possible and its no longer a development job, its mostly technical analysis and troubleshooting of test environments.
Then 5 or 7 years have gone through, and the business decides to replace the system with a new one and the cycle starts again.
The only way i've found to deal with this, is to become a contractor and work mostly on early to mid phases of projects. When the project enters pure maintenance I wait for a few months and then look for a new project.
Work long enough and with many different companies, and you will inevitably have had an experience much like this one. And it's not just in software. Any profession that relies on some form of engineering knows what this is like. There's a reason why Dilbert is so funny.
I say it's a mistake to expect to have creative control at all, over something owned by the corporation you work for. Best to accept that it's not your baby you're working on. You don't get the profits or the glory or any of that. Just do your tasks and treat it like what it is: a job.
Creative control and passion and all that is for side projects and things you build yourself. I just feel it's setting yourself up for disappointment to think otherwise. Companies are not founded to provide the ideal environment for software development. They are founded to make products and hopefully a profit.
You might argue that a smart business person would provide that environment in order to get their product built, and maybe you'd be right, but that also risks building the thing developers want to build as opposed to what could sell. And as soon as you intervene, poof goes the ideal environment. So even if the environment exists at a company, as at the beginning of this story, it's best understood as a happy accident and shouldn't be expected to last.
Creative control and passion and all that is for side projects and things you build yourself. I just feel it's setting yourself up for disappointment to think otherwise. Companies are not founded to provide the ideal environment for software development. They are founded to make products and hopefully a profit.
You might argue that a smart business person would provide that environment in order to get their product built, and maybe you'd be right, but that also risks building the thing developers want to build as opposed to what could sell. And as soon as you intervene, poof goes the ideal environment. So even if the environment exists at a company, as at the beginning of this story, it's best understood as a happy accident and shouldn't be expected to last.
The "Heisenberg Developer" name is really excellent. I recall DeMarco saying in his excellent books (so many years ago): Do not measure anything unless you have a very specific action you want to take based on the data. Why? Because every measurement alters the way programmers work. The author reports that increasing the granularity of the work (and thereby decreasing the time between measurable status updates) led to a lack of refactoring. I have also experienced this one and it led to much head scratching on my part.
Which is not to say that one should not measure. I've never actually used Jira, but apart from that, many of the things the author talks about are generally good ideas: reduce story size to a day or so, prioritise every 2 weeks, measure delivery at about the same interval. Don't throw the baby out with the bath water.
I can say with some confidence that where they went wrong was that they tried to estimate the stories and then they made the cardinal sin of trying to measure the elapsed time for each story. In the first case, you don't need estimates. Each story is a day or so. It's enough granularity. In the case of measuring, there is no organisational benefit. You can see the average throughput of stories. You can estimate your final delivery (especially if you use a defect growth model to estimate how many requirements you are currently missing before delivery). Measuring the actual time of an individual story adds absolutely nothing to your control of the project.
The main argument that I've heard for measuring are two fold. First they feel that measurement will allow people to get better at estimating. Again, it is not needed. If you have a granularity of a day or two in your story sizes (and your throughput is showing that you are achieving that), then you have nothing to improve. If your throughput is not there, then you need to see what the problem is. It will be one of 3 things: your stories are too big, your code is too complicated, your programmers are crap. The first is solved by making your stories smaller, the second is solved by working on technical debt, the third is solved by firing your programmers. I recommend doing everything you can to solve the first, move on to the second, and only then resorting to the third.
What measuring will give you is an idea of the variance in the story sizes. This is unimportant. In fact it is critical not to measure this. All you care about is throughput. Variance is where the developers are putting the extra effort in to improve your throughput (by dealing with technical debt, improving tests in critical areas, creating efficient build systems, writing documentation, etc.). If you remove the variance (as described by the author), you destroy the ability for the developers to optimize throughput.
The second argument for measuring time is to identify stories that are (or were) in trouble. Again, this is unnecessary. First, if you have a story and you are having a hard enough time that it is taking you longer than a day or two, then you already know about it. Asking for help is what stand up is for (and really, I hate to have to say this, but that's all standup is for).
If you are not having trouble, but you are spending a few extra days to refactor something, then you already know about it. Everyone else does too because they can see the code that you refactored.
If you are sitting on your ass and wasting your days writing extremely long posts on HN, then you already know about it. And so does everyone else (because you haven't written any code today, and it's not like you asked for help...).
I'm just going to write this one time. If your reasons for measuring the amount of time for stories is because you secretly think that your developers are crap and that they don't know what they are doing, no amount of measurement is going to solve the problem. Make a decision. Fire them, or not. You can't make a crap programmer good by pointing out how much time they spent on a story. They already know it.
Which is not to say that one should not measure. I've never actually used Jira, but apart from that, many of the things the author talks about are generally good ideas: reduce story size to a day or so, prioritise every 2 weeks, measure delivery at about the same interval. Don't throw the baby out with the bath water.
I can say with some confidence that where they went wrong was that they tried to estimate the stories and then they made the cardinal sin of trying to measure the elapsed time for each story. In the first case, you don't need estimates. Each story is a day or so. It's enough granularity. In the case of measuring, there is no organisational benefit. You can see the average throughput of stories. You can estimate your final delivery (especially if you use a defect growth model to estimate how many requirements you are currently missing before delivery). Measuring the actual time of an individual story adds absolutely nothing to your control of the project.
The main argument that I've heard for measuring are two fold. First they feel that measurement will allow people to get better at estimating. Again, it is not needed. If you have a granularity of a day or two in your story sizes (and your throughput is showing that you are achieving that), then you have nothing to improve. If your throughput is not there, then you need to see what the problem is. It will be one of 3 things: your stories are too big, your code is too complicated, your programmers are crap. The first is solved by making your stories smaller, the second is solved by working on technical debt, the third is solved by firing your programmers. I recommend doing everything you can to solve the first, move on to the second, and only then resorting to the third.
What measuring will give you is an idea of the variance in the story sizes. This is unimportant. In fact it is critical not to measure this. All you care about is throughput. Variance is where the developers are putting the extra effort in to improve your throughput (by dealing with technical debt, improving tests in critical areas, creating efficient build systems, writing documentation, etc.). If you remove the variance (as described by the author), you destroy the ability for the developers to optimize throughput.
The second argument for measuring time is to identify stories that are (or were) in trouble. Again, this is unnecessary. First, if you have a story and you are having a hard enough time that it is taking you longer than a day or two, then you already know about it. Asking for help is what stand up is for (and really, I hate to have to say this, but that's all standup is for).
If you are not having trouble, but you are spending a few extra days to refactor something, then you already know about it. Everyone else does too because they can see the code that you refactored.
If you are sitting on your ass and wasting your days writing extremely long posts on HN, then you already know about it. And so does everyone else (because you haven't written any code today, and it's not like you asked for help...).
I'm just going to write this one time. If your reasons for measuring the amount of time for stories is because you secretly think that your developers are crap and that they don't know what they are doing, no amount of measurement is going to solve the problem. Make a decision. Fire them, or not. You can't make a crap programmer good by pointing out how much time they spent on a story. They already know it.
> (and really, I hate to have to say this, but that's all standup is for)
Hehe, this earned a +1 from me. I've had standups where the scrum master (who also was a lead developer) spent the first 15 minutes talking about what he did the day before.
Hehe, this earned a +1 from me. I've had standups where the scrum master (who also was a lead developer) spent the first 15 minutes talking about what he did the day before.
This post should be pinned to the top of Hacker News.
This is exactly where my job is headed. We hired a project manager who frankly knows nothing about tech. Suddenly, we the developers are no longer able to file tickets ourselves and the tickets themselves need to be blessed and have specs the higher ups can approve. One liner for a hot fix that's filling the error logs? Needs a ticket - a ticket we can't file. All pull requests need one or more associated tickets. I've done my best to actively ignore/subvert it, but it's coming up more and more.
It's incredibly stifling and frustrating and I'm really peeved. It's hard to leave a job I love and have been at for almost 5 years, but we're on a road to hell.
All that said, if anyone needs a Go dev ;)
It's incredibly stifling and frustrating and I'm really peeved. It's hard to leave a job I love and have been at for almost 5 years, but we're on a road to hell.
All that said, if anyone needs a Go dev ;)
Simple fix: apply inner platform effect to your benefit. Either highlight a 'high level feature management tool' (trello/wrike/etc) different to your development workflow, or abuse the current tool by requesting very generalised tickets like 'standing outage prevention' (maintenance!).
No one will reject that because the consequences are lots of revenue.
The problem is not creating tickets. It is the process around them.
Creating a ticket takes seconds and you can even build templates around them if you think they're time consuming. If you cannot report tickets your workflow is wrong.
Creating a ticket takes seconds and you can even build templates around them if you think they're time consuming. If you cannot report tickets your workflow is wrong.
Seconded. You should be able to create tickets or at least file an initial ticket that a PM can flesh out. Tickets (or any type of change control system including git) really serve two purposes. 1) To track what changed 2) To track WHY something changed. A dev should be able to look up your ticket a year from now and be able to untangle the logic in your code changes tied to that ticket. If your ticket only has a title, or the briefest of descriptions you'll find it hard to debug any issues introduced by this (and you'll also be going to dev hell)
That really assumes that
1) Tickets are detailed enough and have been for a long enough period of time.
2) The functionality that's to blame was implemented in one ticket.
Unfortunately, that's almost never true anymore for anyone.
1) Tickets are detailed enough and have been for a long enough period of time.
2) The functionality that's to blame was implemented in one ticket.
Unfortunately, that's almost never true anymore for anyone.
git bisect + git blame I find usually more useful than verbose likely partially correct notes.
That often tells What changed, but rarely does it seem to tell Why. When the logic changes (and tests too) because the sales team now needs Different Things, it's very useful to have a ticket.
That doesn't scale to large or multiple teams.
Every time I read something like this (because experiencing is just to traumatic to remember) I tend to share http://algeri-wong.com/yishan/engineering-management.html
One day I hope to find some place small that applies that by the 'book'.
My personal anecdote was, that no matter how much I tried to persuade the PM that it's a bad idea to put all the platforms (iOS, Web, Android, etc) stories and bugs into one giant tracker (Pivotal Tracker) we ended up doing that.... until the sudden realisation that it's a bad idea. It's hard to believe that PM had been on software projects before.
Found a typo in what is otherwise awesome writing, "loosing".
One day I hope to find some place small that applies that by the 'book'.
My personal anecdote was, that no matter how much I tried to persuade the PM that it's a bad idea to put all the platforms (iOS, Web, Android, etc) stories and bugs into one giant tracker (Pivotal Tracker) we ended up doing that.... until the sudden realisation that it's a bad idea. It's hard to believe that PM had been on software projects before.
Found a typo in what is otherwise awesome writing, "loosing".
Why is this a problem as long as bugs are separated by component? Sometimes a feature will require work on multiple platforms, and it's nice to go to one place to get a sense of overall progress. And, since the bugs/tasks are separated by component, you can get the granular view you want as well.
You could get overall progress even with separated boards.
Overall progress doesn't help us who have to open/close/comment on them. You wouldn't use a single issue tracker for five repos, how is this different?
Regardless, they wanted to switch once they realized how cluttered things became for non-devs as well.
Overall progress doesn't help us who have to open/close/comment on them. You wouldn't use a single issue tracker for five repos, how is this different?
Regardless, they wanted to switch once they realized how cluttered things became for non-devs as well.
As a developer, I love having tickets linked to changes! It makes it trivial to trace a git merge to a review and then the original use case.
This allows commit messages to be more succinct and technical.
Also, if your company is publicly traded in the US, there are requirements to document changes from SOX.
This allows commit messages to be more succinct and technical.
Also, if your company is publicly traded in the US, there are requirements to document changes from SOX.
We're privately owned, but that is an interesting thought I'd never even considered.
This is very true. My experience has always been that my team performed better when there were /less/ controls on their time, rather than more. I also found it was important to explain the reasons /why/ a particular thing needed to be done by a certain date, on the occasions that some external pressure needed it to be done.
People don't mind pulling out the stops and working extra hard, as long as it's occasional and /necessary/. It's absolutely morale-killing to do so for an arbitrary deadline, however. Nothing burns out a team faster than death-marches to deadlines pulled from thin air.
People don't mind pulling out the stops and working extra hard, as long as it's occasional and /necessary/. It's absolutely morale-killing to do so for an arbitrary deadline, however. Nothing burns out a team faster than death-marches to deadlines pulled from thin air.
And of course, the other key part of that is that you should consider those exceptional cases to be exceptions, in the sense of errors.
When production goes down, or the sales team overpromises, don't just fix it, figure out why it happened and do the full root cause analysis.
When production goes down, or the sales team overpromises, don't just fix it, figure out why it happened and do the full root cause analysis.
One issue with how developers are hired these days, is many large companies are hiring largely for classical knowledge (aka, memorizing: Algorithms, DS) and mathematical ability. Try interviewing at MS, big G or Amazon and you will see what I mean.
These developers are great as code monkeys, but a lot of them don't have any idea what their code contributes to, or even how their business makes money. I attended a hackathon with a number of Amazon employees, and one of my distinct memories was a Principal Engineer who didn't even know what "publicly traded" meant and was sure that Bezos owned 100% of the company.
A potential solution to this issue, is to hire engineers with more diverse skillsets. Deep understanding of mathematics and classical algorithms is fantastic for software performance, and low level details.
On the other hand, at a tech company - your software is literally your revenue stream. You are hiring people who don't understand your business - to build and grow your business.
Maybe hire some developers with strong business skills, and a good understanding of the economy and your market - and put them on a team with more traditional engineers. In doing so, you get someone with the big picture, and someone with the details working together and might not even need another PM.
Just my thoughts.
These developers are great as code monkeys, but a lot of them don't have any idea what their code contributes to, or even how their business makes money. I attended a hackathon with a number of Amazon employees, and one of my distinct memories was a Principal Engineer who didn't even know what "publicly traded" meant and was sure that Bezos owned 100% of the company.
A potential solution to this issue, is to hire engineers with more diverse skillsets. Deep understanding of mathematics and classical algorithms is fantastic for software performance, and low level details.
On the other hand, at a tech company - your software is literally your revenue stream. You are hiring people who don't understand your business - to build and grow your business.
Maybe hire some developers with strong business skills, and a good understanding of the economy and your market - and put them on a team with more traditional engineers. In doing so, you get someone with the big picture, and someone with the details working together and might not even need another PM.
Just my thoughts.
Anecdotal I know but I've been told that my business knowledge and curiosity is not welcome nor wanted whilst developing and that I should be more single minded to churning out code. We live in an economic environment where specialisation is valued over all else. Polymaths and generalists struggle in this environment unless they found the business themselves or are lucky enough to get picked up by a large company to head up a team.
I spent my teenage years building fan sites and social networking sites for games. I made enough money to pay off college, get a nice apartment by the water and have a couple k leftover come graduation.
I was curious why I wasn't getting a lot of hits on my resume, so I talked to a recruiter at a networking event who had seen my application (for one of the "unicorns") and she said they where uncomfortable with how entrepreneurial it looked.
I removed the sections from my resume, removed all of my contract work too - only listed the internships and found some other grads (that got jobs) resumes to copy the language style. Pretty much instantly my resume was getting me double or triple the interviews.
Bummer too, because I worked my ass off and always had the false impression that employers would like that.
Sometimes its the gap between marketing (how they want the company to appear) and HR I think. Marketing wants innovators, HR wants workhorses that move in a strait line and don't try new things.
I was curious why I wasn't getting a lot of hits on my resume, so I talked to a recruiter at a networking event who had seen my application (for one of the "unicorns") and she said they where uncomfortable with how entrepreneurial it looked.
I removed the sections from my resume, removed all of my contract work too - only listed the internships and found some other grads (that got jobs) resumes to copy the language style. Pretty much instantly my resume was getting me double or triple the interviews.
Bummer too, because I worked my ass off and always had the false impression that employers would like that.
Sometimes its the gap between marketing (how they want the company to appear) and HR I think. Marketing wants innovators, HR wants workhorses that move in a strait line and don't try new things.
That's odd. We get excited when we see an entrepreneurial profile like yours. We have several developers who want to start companies and actually try to help them along that path.
The benefit to a motivated engineer is you can give them problems to solve instead of specs. The outcome or results can be less predictable but can also be much more effective.
The benefit to a motivated engineer is you can give them problems to solve instead of specs. The outcome or results can be less predictable but can also be much more effective.
When I got out of contracting, and later after 2008 business failure, I lost count of interviews that went thus:
"You're perfect for the role", "You have just the skills we need", "you're by far the best of those interviewed"
but by email later, sometimes directly
"we think you'll get bored", "we think you'll leave after six months" etc
(Sometimes, "we think you're a bit overqualified")
For sanity's sake I went on a few contract interviews, and usually got an offer.
My experience was that employers are utterly terrified of someone who's got some entrepreneurial or business history. Sure the money was less, but there many reasons to want to go back to employment.
As they didn't like it, I always wondered why so many invited me to interview when the 5 years of successful business and 4 years of contracting was very clear to see on my resume.
"You're perfect for the role", "You have just the skills we need", "you're by far the best of those interviewed"
but by email later, sometimes directly
"we think you'll get bored", "we think you'll leave after six months" etc
(Sometimes, "we think you're a bit overqualified")
For sanity's sake I went on a few contract interviews, and usually got an offer.
My experience was that employers are utterly terrified of someone who's got some entrepreneurial or business history. Sure the money was less, but there many reasons to want to go back to employment.
As they didn't like it, I always wondered why so many invited me to interview when the 5 years of successful business and 4 years of contracting was very clear to see on my resume.
I've had the same experience as the poster you're replying to. I had to remove any bits of the fact that I bootstrapped my own fledgling (small, successful in it's own right, yet not capable of sustaining full-time wages) startup from my resume to get interviews. I was told that my resume was "intimidating" and "sending the wrong signal" by friends who are developers whose input I trust.
But I completely agree with what you've said. I am a problem solver or a product engineer or whatever this skill set combination is being called these days. I pull from a wide range of experiences to solve problems and I'm not very happy when I have to work off of a rigorous spec.
Unfortunately, that doesn't mean much to most employers in my experience. I don't fit in to most places and most places don't know what to do with me. It's made for a rather frustrating career over the last decade but I simply don't know what else to do.
But I completely agree with what you've said. I am a problem solver or a product engineer or whatever this skill set combination is being called these days. I pull from a wide range of experiences to solve problems and I'm not very happy when I have to work off of a rigorous spec.
Unfortunately, that doesn't mean much to most employers in my experience. I don't fit in to most places and most places don't know what to do with me. It's made for a rather frustrating career over the last decade but I simply don't know what else to do.
How do you feel about the potential for high turnover with entrepreneurial types, as it seems the general consensus is they will inevitably leave to start their own thing? How long do you expect someone to work for you before hiring them, getting them up to speed with your system, and integrating them into the company is a worthwhile investment?
When I get asked this in an interview, I always answer the same way: yes, I will probably go to the next gig faster than other employees. But I will get up to speed faster, and I will produce more output for the business itself in the time I'll spend in your company.
It might be a question of commitment signaling. Some reviewers might ding candidates that seem to have a ton of work going on outside of work. Maybe even more so if they see a candidate hasn't held a job > a certain # of years before.
Not sure if HR thinks that deeply during resume review, though. If you're not getting past that screen it's probably just match-the-buzzwords-listed-in-posting density—more "filler" words (started awesome website, did amazing things) means less % matching words
Not sure if HR thinks that deeply during resume review, though. If you're not getting past that screen it's probably just match-the-buzzwords-listed-in-posting density—more "filler" words (started awesome website, did amazing things) means less % matching words
Young engineer, I tried being entrepreneurial. I confirm team leads don't like it, even if the company displays the marketing you describe. Better become more skilled in your field than just overly motivated. It's sad that we only understand that after a few years in the job.
I had a similar background--worked my way through school doing small to medium size freelance projects. Much of my freelance work was contracting for one company (where I was mentored by one the senior developers) and few startups, so it wasn't quite as bad as what you experienced. Some employers think you're not "office material" if you happened to be a hard-working, independent worker that managed to pay their way through school while learning on the job. I assume I probably dodged a bullet working at any of those places, if that's the way they hire.
After graduation, I had a few tell companies me that my work during school as sort of a "black mark" and I think it's sort of humorous looking back at it now. Currently, I'm the technical lead for my dev team and the contract work I did while in school is probably the best experience I had for the work I do now. Gave me a broad range of experience that reinforced the theory and concepts I was learning while in school.
After graduation, I had a few tell companies me that my work during school as sort of a "black mark" and I think it's sort of humorous looking back at it now. Currently, I'm the technical lead for my dev team and the contract work I did while in school is probably the best experience I had for the work I do now. Gave me a broad range of experience that reinforced the theory and concepts I was learning while in school.
Interesting. Perhaps something I can learn from. What kind of companies have you worked for (large corps / startups / SMEs?) and what kind of work do you do for them (any specialisations)? How do these experiences contrast to your pre-employment/self-employment experiences?
I do full-stack development. Front-end, back-end, some server admin, DB, UX, SEO, etc.
I worked at a F500 building tools to visualize big data and had a great time. Learned a lot and had a lot of freedom.
Afterwards, a VC funded startup - didn't really fit in, most of my co-workers where hardcore academics and it had a lot of micromanaging.
Also did some contract gigs, subcontracting for another company which could be good, bad or neutral (all depends on the client).
Self-employement is awesome, because you get to explore a ton of new things. You get to learn about SEO, business models, cutting costs to increase profits, increasing conversions, brand image, UX, etc. You also get to know your audience really well.
In my case, the biggest downside is I could never build a strong network because most of my revenue was coming from ads and donations and the target audience was younger.
It's easier to network when you are out and about, and always working with people who have their own networks.
I'd love to start a company (on a bigger scale) some day, when I have a stronger network, a larger skillset, and some capital so I can make sure I am feeding myself every week :)
I worked at a F500 building tools to visualize big data and had a great time. Learned a lot and had a lot of freedom.
Afterwards, a VC funded startup - didn't really fit in, most of my co-workers where hardcore academics and it had a lot of micromanaging.
Also did some contract gigs, subcontracting for another company which could be good, bad or neutral (all depends on the client).
Self-employement is awesome, because you get to explore a ton of new things. You get to learn about SEO, business models, cutting costs to increase profits, increasing conversions, brand image, UX, etc. You also get to know your audience really well.
In my case, the biggest downside is I could never build a strong network because most of my revenue was coming from ads and donations and the target audience was younger.
It's easier to network when you are out and about, and always working with people who have their own networks.
I'd love to start a company (on a bigger scale) some day, when I have a stronger network, a larger skillset, and some capital so I can make sure I am feeding myself every week :)
How did user testing go for the UX portion of your work?
Is HR the first line of contact when applying in most companies? Where I work I think we (the developers) get all the resumes that come in and decide to decline or continue the process, HR only handles the logistics
May be you should've applied to different companies with different values?
That's a sign that you have what it takes to start consulting on your own. Every client I've ever had has appreciated my non-programming skills. I've never taken a client until I thoroughly understood the business and I have rejected many potential clients because I did not agree with the business-end of the software need.
Specialization is indeed valuable but it's not a binary master-of-one vs jack-of-all market. I am A+ in a specific platform, A in a couple of market segments, B+ in a handful of valuable technologies, B in many professional skills, C+ in most business activities, and C in everything that I have never encountered before. I don't need to be A+ in everything I touch and I am definitely not just a C in every single trade.
You don't have to start a business or be lucky enough to head up a team at a large business to get a chance to apply your skills fully. I don't want to do either so I consult with small-to-mid-sized business and research+plan+code+test+train whatever they need. For someone on a W2, this seems unconventional and risky. Don't want to sugar-coat it - it is. But what it's not is unsatisfying.
If you are in a position in life to take a small risk on yourself, pick up a small consulting gig that is more than just pure coding/technical. The more you perform like a vendor and business partner and less like an hourly contract employee, the closer you get to applying your full range of skills.
Specialization is indeed valuable but it's not a binary master-of-one vs jack-of-all market. I am A+ in a specific platform, A in a couple of market segments, B+ in a handful of valuable technologies, B in many professional skills, C+ in most business activities, and C in everything that I have never encountered before. I don't need to be A+ in everything I touch and I am definitely not just a C in every single trade.
You don't have to start a business or be lucky enough to head up a team at a large business to get a chance to apply your skills fully. I don't want to do either so I consult with small-to-mid-sized business and research+plan+code+test+train whatever they need. For someone on a W2, this seems unconventional and risky. Don't want to sugar-coat it - it is. But what it's not is unsatisfying.
If you are in a position in life to take a small risk on yourself, pick up a small consulting gig that is more than just pure coding/technical. The more you perform like a vendor and business partner and less like an hourly contract employee, the closer you get to applying your full range of skills.
I appreciate your perspective however right now, due to personal circumstances/ bureaucratic reasons, I need a full-time job. I have run my own businesses previously and enjoyed it immensely however they also burnt me out. I learnt a lot from this that I will take with me. My experiences since then have made me realise I should apply the approach from your 1st paragraph more in future.
No worries mate. Though notice I said consulting repeatedly and contrasted it with running a business or being employed. You can sell your services without having to run a business. I don't want to hire anyone, advertise, have an LLC/S-Corp to manage, deal with licensing, or even print business cards. I just want to show up, do the work, and get a check.
Like anything, it depends. If you don't like being a cog in a large machine, look to smaller shops. I hate working in large firms precisely because I'm bad at shutting up and being a cog.
And you know what? In big shops, painting outside of your lines actually can cause problems. Questioning decisions on things going on outside of one's domain causes slowdown (at the very least, wasted time in meetings where people explain why that stupid idea actually has to be that way, etc.) and frequently, conflict, because when the norm is "stay in your (metaphorical) cube", questioning decisions can all too easily look like an accusation of incompetence or as a power play.
Go where your other skills have value.
And you know what? In big shops, painting outside of your lines actually can cause problems. Questioning decisions on things going on outside of one's domain causes slowdown (at the very least, wasted time in meetings where people explain why that stupid idea actually has to be that way, etc.) and frequently, conflict, because when the norm is "stay in your (metaphorical) cube", questioning decisions can all too easily look like an accusation of incompetence or as a power play.
Go where your other skills have value.
I think it depends on the job for which you're applying.
We want our senior developers to be willing to dig into business requirements and constraints without being asked to. Curiosity, orthogonal business knowledge, etc are important at that level and higher.
However, we've seen multiple times that the junior developers just can't do it with the rare exception. They have enough work getting up to speed on one or more of: the language, the large internal system, the large client systems, how the client works, how to be an employee, how to deliver value over the long term and not go 2 weeks with no delivery then 2 weeks with, etc.
We want our senior developers to be willing to dig into business requirements and constraints without being asked to. Curiosity, orthogonal business knowledge, etc are important at that level and higher.
However, we've seen multiple times that the junior developers just can't do it with the rare exception. They have enough work getting up to speed on one or more of: the language, the large internal system, the large client systems, how the client works, how to be an employee, how to deliver value over the long term and not go 2 weeks with no delivery then 2 weeks with, etc.
You're right, sounds like maybe a bit of over-generalization from your situation :)
Do you have a direct manager who talks with you about your career growth? A good one might help you find projects that engage your broader interests. There are certainly roles and projects that involve some degree of inter disciplinary work, and not just at founder or team lead levels. If not at your company, there are certainly some at others. Startups especially welcome diverse contributions from early employees.
Hope you find a good outlet for your interests! If not in an engineering role, maybe try a side project.
Do you have a direct manager who talks with you about your career growth? A good one might help you find projects that engage your broader interests. There are certainly roles and projects that involve some degree of inter disciplinary work, and not just at founder or team lead levels. If not at your company, there are certainly some at others. Startups especially welcome diverse contributions from early employees.
Hope you find a good outlet for your interests! If not in an engineering role, maybe try a side project.
I was always interested in technical PM roles, but I'm best at full-stack development. The most important work criteria for me, is to see the business as something I'd invest in. If I think the product matters (can have a serious positive impact on it's customers, rather than a marginal one), it's easy to get excited about it.
I have a few dev managers and experienced engineers who I've kept in contact with from an old summer gig - they all think I should join/create a startup.
I'm actually on the job market right now (Seattle) - but considering moving to CA because recruiters in that area seem to like me a lot more. Might be a culture thing.
I have a few dev managers and experienced engineers who I've kept in contact with from an old summer gig - they all think I should join/create a startup.
I'm actually on the job market right now (Seattle) - but considering moving to CA because recruiters in that area seem to like me a lot more. Might be a culture thing.
I feel the same way, it's hard to care about something you wouldn't use or evangelise about, unless it's deeply niche and complicated enough to go over my head and make me feel dumb.
Well it looks like you got a positive signal from Instacart :) Good luck with the hunt.
Thanks for your kind words of encouragement. I have decided to specialise in machine learning. It perfectly suits my analytical and technical appetite. Also I would love to work in robotics so it seems like a natural path. Btw: nice site http://codingforinterviews.com/ . I will definitely give it a go :)
Don't work in a company with the people who told you that. It's not only wrong, it's bad for business, and I constantly see the negative consequences of this worldview.
Geeky (single focus) developers are
- cheaper
- do not get distracted by politics / business
- easier to control / manipulate into lower salaries
- do not get distracted by politics / business
- easier to control / manipulate into lower salaries
I seriously doubt there's any supporting evidence for the idea that people focuses on coding over business have any trouble negotiating a reasonable salary.
Lots of cognitive bias there.
I agree. In fact, the more I look at this problem, the more convinced I become that coding shouldn't be an end to itself. Very few companies need super-smart generic programmer cut-outs. Instead, they need business folks who can program.
It makes sense if you think about it. If software is truly eating the world, it's an upheaval on the scale of writing. Nobody hires specialized people to write; that's idiotic. Writing is so closely associated with what we do day-to-day that whatever your job (in the business sector), you're expected to be able to form a sentence and write it down. Same goes for programming.
I have no idea how long it will take to fully make the transition. A hundred years? Twenty? It'll be interesting to watch, though!
It makes sense if you think about it. If software is truly eating the world, it's an upheaval on the scale of writing. Nobody hires specialized people to write; that's idiotic. Writing is so closely associated with what we do day-to-day that whatever your job (in the business sector), you're expected to be able to form a sentence and write it down. Same goes for programming.
I have no idea how long it will take to fully make the transition. A hundred years? Twenty? It'll be interesting to watch, though!
That sounds like a good idea, until you realize that developers with a strong grasp of coding AND business are rather rare. If you're a growing business, it's hard enough to find enough really good devs as it is, and now you want to add in another, orthogonal skill set? Good luck with that.
Ask not what your left or right brain can do for you. Ask what both of them combined can do for your company.
Off topic, but that doesn't resonate for me.
Can't say much for MS, but for the others the essential CS skills questions (should be...) relatively uniform for all experience levels. i.e. they are at graduate level.
Plus, Amazon count on these 'a lot' https://www.amazon.jobs/principles
Possibly more than the CS side of things in my experience.
Can't say much for MS, but for the others the essential CS skills questions (should be...) relatively uniform for all experience levels. i.e. they are at graduate level.
Plus, Amazon count on these 'a lot' https://www.amazon.jobs/principles
Possibly more than the CS side of things in my experience.
Triplebyte has a blogpost[1] that seems quite relevant. Most companies seem to want "product programmers"[2], as opposed to technical or enterprise programmers. The second link below is another blogpost by them explaining this taxonomy.
It would be interesting to see how much this applies to non y-combinator companies (which is what their study covered), but I'd have a guess and say that, for most startups, quite a lot.
1. https://data.triplebyte.com/who-y-combinator-companies-want-... 2. https://data.triplebyte.com/a-taxonomy-of-programmers-d0e9d8...
It would be interesting to see how much this applies to non y-combinator companies (which is what their study covered), but I'd have a guess and say that, for most startups, quite a lot.
1. https://data.triplebyte.com/who-y-combinator-companies-want-... 2. https://data.triplebyte.com/a-taxonomy-of-programmers-d0e9d8...
> I attended a hackathon with a number of Amazon employees, and one of my distinct memories was a Principal Engineer who didn't even know what "publicly traded" meant and was sure that Bezos owned 100% of the company.
It's not clear to me why that knowledge would be especially useful to a principle engineer at Amazon. I think it's a generally good thing to know, and difficult to avoid picking up. But clearly someone did avoid it, and I don't particularly expect that to reflect in their engineering competence.
It's not clear to me why that knowledge would be especially useful to a principle engineer at Amazon. I think it's a generally good thing to know, and difficult to avoid picking up. But clearly someone did avoid it, and I don't particularly expect that to reflect in their engineering competence.
> It's not clear to me why that knowledge would be especially useful to a principle engineer at Amazon.
Assuming that Amazon has any equity portion to compensation (which is common in even large tech companies, not just startups, though I don't have any direct knowledge of Amazon's typical pay arrangements) its pretty critical to understanding what he is getting in exchange for the labor he provides, so there's that.
Assuming that Amazon has any equity portion to compensation (which is common in even large tech companies, not just startups, though I don't have any direct knowledge of Amazon's typical pay arrangements) its pretty critical to understanding what he is getting in exchange for the labor he provides, so there's that.
What would you think of a government employee who didn't know the US was a democracy?
Depends on the role. For example, I think a postman is a government employee? In that case, about the same as I'd think of an Amazon engineer who didn't know that. I have no idea how they don't know it, and I think a little less of them for it. But if it's not relevant for their work, I don't judge their skill by it, and I don't think less of them than I do of anyone else.
If you want me to be - offended? shocked? contemptuous? - of what someone doesn't know, please tell me why it's so important for them to know it. Not just why it could potentially be useful for someone in their role. Why it's so important for anyone in this role, that this particular thing gets singled out, suggests in lieu of all other data that they're incompetent.
I'm an engineer at a publicly traded company. (Or so I assume. I could be mistaken.) I can think of dozens of things I don't know that would be useful for me to know. I do know what a publicly traded company is, but this knowledge is not useful for me in my role.
If you want me to be - offended? shocked? contemptuous? - of what someone doesn't know, please tell me why it's so important for them to know it. Not just why it could potentially be useful for someone in their role. Why it's so important for anyone in this role, that this particular thing gets singled out, suggests in lieu of all other data that they're incompetent.
I'm an engineer at a publicly traded company. (Or so I assume. I could be mistaken.) I can think of dozens of things I don't know that would be useful for me to know. I do know what a publicly traded company is, but this knowledge is not useful for me in my role.
Would you want to work with someone who "is sure" of a trivially verifiable fact? It's ok to be ignorant ("I have no idea who owns what") but to be sure of something that pants-on-head false?
What else are they "sure" about?
What else are they "sure" about?
Well it isn't. Officially it is a republic. A democratic one, but a republic. Unofficially political power is so unevenly distributed it should be called an oligarchy. Officially, North Korea is also a republic.
Now, if the person thought the President was a king of a monarchy, then I would say they have been listening to too much talk radio.
Now, if the person thought the President was a king of a monarchy, then I would say they have been listening to too much talk radio.
> Well it isn't.
Yes, it is. Or, at least, if not, not for the first reason you present.
> Officially it is a republic. A democratic one, but a republic.
A democratic republic is still a democracy (usually, a representative democracy, but since any political system which isn't a monarchy can be correctly called a "republic", a direct democracy could also be a democratic republic.)
The idea that "democracy" and "republic" are mutually exclusive categories is quite wrong.
> Unofficially political power is so unevenly distributed it should be called an oligarchy.
And so connected to wealth that it should be called plutocracy, according to some, sure.
> Officially, North Korea is also a republic.
And a democratic one, too.
Yes, it is. Or, at least, if not, not for the first reason you present.
> Officially it is a republic. A democratic one, but a republic.
A democratic republic is still a democracy (usually, a representative democracy, but since any political system which isn't a monarchy can be correctly called a "republic", a direct democracy could also be a democratic republic.)
The idea that "democracy" and "republic" are mutually exclusive categories is quite wrong.
> Unofficially political power is so unevenly distributed it should be called an oligarchy.
And so connected to wealth that it should be called plutocracy, according to some, sure.
> Officially, North Korea is also a republic.
And a democratic one, too.
Originally I was going to say "democratic republic" but then it becomes a game of minutia. Not knowing that Amazon is controlled by a board of directors (elected by shareholders, the owners) is just like not realizing the president is elected and we don't have King Obama.
> Not knowing that Amazon is controlled by a board of directors (elected by shareholders, the owners) is just like not realizing the president is elected and we don't have King Obama.
Sure, and it would be very surprising for anyone not to know that, but I don't see how it makes them any less qualified to do their job.
Sure, and it would be very surprising for anyone not to know that, but I don't see how it makes them any less qualified to do their job.
If someone believed in King Obama, would your surprise elevate or diminish your confidence in their general-purpose information gathering skills?
This would be a good analogy if the guy didn't know he worked for a tech company.
> I attended a hackathon with a number of Amazon employees, and one of my distinct memories was a Principal Engineer who didn't even know what "publicly traded" meant and was sure that Bezos owned 100% of the company.
This is terrifying. I wouldn't be surprised if his 401(k) was 100% Amazon stock "because that's where he works" or something.
This is terrifying. I wouldn't be surprised if his 401(k) was 100% Amazon stock "because that's where he works" or something.
100% of what stock, didn't Bezos own everything?
What is it about programming as a profession that attracts people who believe they are all things? When becoming a civil engineer do you take a large number of business courses? When becoming an electrical engineer do you take a large number of business courses? When becoming a doctor do you take a large number of business courses? When becoming an astrophysicist do you take a large number of business courses?
Why are you not suggesting that ethics should be a larger portion of the programmer's training and skill set. Perhaps while building the infrastructure for the next century we should all think long and hard about the ethical implications of what we're building rather than just racing to get the next round of funding or a positive report by some Wall Street analyst on the other side of the country.
Most code bases look as though they've been built by business analysts rather than professional software engineers. The number of security exploits is a testament to this in practice. What we have here is basically a repeat of Wall Street's bond market in the 80's, just in a different industry. Because of the market fundamentals most any idiot was making a killing. Most of these bond traders actually were not terribly bright, but they were making money hand over fist, and so, they thought they were geniuses. In the end it really didn't work out well for anyone. For a good overview of what I'm referring to you can read "Liar's Poker."
Eventually these idiots were replaced with professionals, and to work at any of these shops one must now first prove, through both schooling and certification, that one has a solid grasp of a large knowledge base. If you want to become a portfolio manager, and you already graduated from Columbia with a degree in finance, that's great but you still need to go get your CFA. Google CFA and then compare that to your average programming interview. Just the Level 1 exam has over 3,000 pages of material. There are 3 levels. You basically don't have a social life for 18 months. And most of the time this is something one does while holding down a full time job that already assumes they own your free time. Lawyer's bar exams and the Board Certification process are equally grueling.
I'd be very happy with more of an emphasis on classical knowledge. A strong foundation based on a knowledge base of classical knowledge is the foundation of any professional engineering society. Patronizing someone with a firm grasp on this knowledge by saying that they are "great as code monkeys" betrays an enormously immature approach to one's profession.
Why are you not suggesting that ethics should be a larger portion of the programmer's training and skill set. Perhaps while building the infrastructure for the next century we should all think long and hard about the ethical implications of what we're building rather than just racing to get the next round of funding or a positive report by some Wall Street analyst on the other side of the country.
Most code bases look as though they've been built by business analysts rather than professional software engineers. The number of security exploits is a testament to this in practice. What we have here is basically a repeat of Wall Street's bond market in the 80's, just in a different industry. Because of the market fundamentals most any idiot was making a killing. Most of these bond traders actually were not terribly bright, but they were making money hand over fist, and so, they thought they were geniuses. In the end it really didn't work out well for anyone. For a good overview of what I'm referring to you can read "Liar's Poker."
Eventually these idiots were replaced with professionals, and to work at any of these shops one must now first prove, through both schooling and certification, that one has a solid grasp of a large knowledge base. If you want to become a portfolio manager, and you already graduated from Columbia with a degree in finance, that's great but you still need to go get your CFA. Google CFA and then compare that to your average programming interview. Just the Level 1 exam has over 3,000 pages of material. There are 3 levels. You basically don't have a social life for 18 months. And most of the time this is something one does while holding down a full time job that already assumes they own your free time. Lawyer's bar exams and the Board Certification process are equally grueling.
I'd be very happy with more of an emphasis on classical knowledge. A strong foundation based on a knowledge base of classical knowledge is the foundation of any professional engineering society. Patronizing someone with a firm grasp on this knowledge by saying that they are "great as code monkeys" betrays an enormously immature approach to one's profession.
My experience in interviews is that my interest in and focus on the end product and business make me appear more lightweight technically. "Not enough of a nerd"...basically.
Many developers prefer to work like Navy Seals or Jazz Musicians. It's objectively more empowering, arguably more fun.
Some jobs require an army or a big band, i.e., a lot of coordinated precision - objectively less freedom and autonomy, arguably more tedious.
Beyond some threshold of granularity you will crush morale though.
Do what makes you happy.
Some jobs require an army or a big band, i.e., a lot of coordinated precision - objectively less freedom and autonomy, arguably more tedious.
Beyond some threshold of granularity you will crush morale though.
Do what makes you happy.
I think context is important here. What is the software you are building? Is it highly critical or possibly life threatening, like a stock exchange trading system or a aeroplane control system? Should the developers be given autonomy to speed delivery? Or should more controls be put in place to ensure delivery of the quality, validated product while possibly slowing down the delivery speed.
The story begins with a new feature request that the "business" thinks is needed while the "developers" think is not. It's really hard to pick sides here without knowing more about the specifics. I've seen situations where developers are completely wrong about the business value of something and I've seen it the other way around.
If the new feature was indeed critical to the business then the boss finds himself in a situation where one of the best developers spends months trying to build some DSL and comes back with nothing. So we can understand the frustration on the business side of things. This is where things started going the wrong way and there's a loss of trust on the ability of the technical team to deliver.
Now obviously the new PM and his buddies (I've seen this before) only make everything worse. "Jira" or "Scrum" or "Agile" wasn't really appreciated by the old team used to doing whatever they wanted to do.
I think the truth here is there has to be some sort of balance. Developers need to balance architecture and refactoring with delivering new stuff. They need to listen and have a dialog with product management about new features. There has to be trust. When there is trust there are less controls. When trust is lost it's almost an unfixable situation especially when you have a combination of a tech team that isn't delivering anything useful (from the business perspective) with management who doesn't understand software development.
Clearly the best situation is trust combined with good management and developers who take ownership and see the big picture. Then useful stuff gets delivered and things like architecture or refactoring get taken care of.
If the new feature was indeed critical to the business then the boss finds himself in a situation where one of the best developers spends months trying to build some DSL and comes back with nothing. So we can understand the frustration on the business side of things. This is where things started going the wrong way and there's a loss of trust on the ability of the technical team to deliver.
Now obviously the new PM and his buddies (I've seen this before) only make everything worse. "Jira" or "Scrum" or "Agile" wasn't really appreciated by the old team used to doing whatever they wanted to do.
I think the truth here is there has to be some sort of balance. Developers need to balance architecture and refactoring with delivering new stuff. They need to listen and have a dialog with product management about new features. There has to be trust. When there is trust there are less controls. When trust is lost it's almost an unfixable situation especially when you have a combination of a tech team that isn't delivering anything useful (from the business perspective) with management who doesn't understand software development.
Clearly the best situation is trust combined with good management and developers who take ownership and see the big picture. Then useful stuff gets delivered and things like architecture or refactoring get taken care of.
> "business" thinks is needed while the "developers" think is not
Some correction here: "business" thinks is needed, while "developers" think is impossible. Have you really never seen that happen?
Then, a developer gets a great idea that turn an impossible idea into a possible mega-project. But, for lack of experience with this kind of project, thinks it's an small, viable one. Then, the project fails - big duh.
What's a problem here is that all it takes is one instance of this happening to the management to declare its team a failure and replace everything. Without any inspection or introspection. That's (if the history is complete) a profound lack of professionalism.
Some correction here: "business" thinks is needed, while "developers" think is impossible. Have you really never seen that happen?
Then, a developer gets a great idea that turn an impossible idea into a possible mega-project. But, for lack of experience with this kind of project, thinks it's an small, viable one. Then, the project fails - big duh.
What's a problem here is that all it takes is one instance of this happening to the management to declare its team a failure and replace everything. Without any inspection or introspection. That's (if the history is complete) a profound lack of professionalism.
> Now obviously the new PM and his buddies (I've seen this before) only make everything worse. "Jira" or "Scrum" or "Agile" wasn't really appreciated by the old team used to doing whatever they wanted to do.
Everything I have read about agile is that if you do it right, everyone is happy. The customer, the developers, and the managers. Agile itself is supposed to be development-centric.
Tonight, I realized that Agile does not handle politics very well. I mean, how can it? It's just a software development methodology.
Everything I have read about agile is that if you do it right, everyone is happy. The customer, the developers, and the managers. Agile itself is supposed to be development-centric.
Tonight, I realized that Agile does not handle politics very well. I mean, how can it? It's just a software development methodology.
> Everything I have read about agile is that if you do it right, everyone is happy. The customer, the developers, and the managers.
So they said about all its predecessors, as well. Pretty soon, they start adding "...of course, you must have exceptionally competent people", and then they define 'doing it right' by 'having a successful outcome'.
Problem solved by begging the question.
So they said about all its predecessors, as well. Pretty soon, they start adding "...of course, you must have exceptionally competent people", and then they define 'doing it right' by 'having a successful outcome'.
Problem solved by begging the question.
Take a read at the Agile Manifesto, and I doubt you'll find any point there to criticize.
But then, take a look at any agile methodology, and try to explain how it fits the manifesto. Or better, explain how adopting any "agile methodology" fits the manifesto by itself.
But then, take a look at any agile methodology, and try to explain how it fits the manifesto. Or better, explain how adopting any "agile methodology" fits the manifesto by itself.
It turns out that software development is a very immature industry. We simply don't know how to judge successful software projects/developers.
In the face of that immaturity we can try all kinds of things. Personally, I do anarchist development and hope for the best. Others try cargo cult project management. Still others move to highly constrained development methodologies.
In the face of that immaturity we can try all kinds of things. Personally, I do anarchist development and hope for the best. Others try cargo cult project management. Still others move to highly constrained development methodologies.
Successful software is software that implements its functional and non-functional requirements at a reasonable cost. There.
Yet interesting enough, that definition doesn't mention any of the actual reasons why you'd build software and doesn't speak to end-user/customer/client happiness.
It also implies at least, that we can collect requirements in some adequate way, which is really a circular argument. Requirements gathering is even less mature than other parts of software development.
It also implies at least, that we can collect requirements in some adequate way, which is really a circular argument. Requirements gathering is even less mature than other parts of software development.
"why you build software" = requirement.
end-user/customer/client happiness = Customer satisfaction surveys and ratings help you acquiring it. Basic KPIs such as retention rates and engagement can also help you understand this.
A/B testing helps the process of testing assumptions in a data driven way.
A/B testing helps the process of testing assumptions in a data driven way.
That is a definition of requirement that is different than what most of the industry uses. Most of the industry sees requirements as "how the software should behave". Even with your new definition, I've seen little evidence that we have mature processes around collecting requirements.
As for surveys, KPIs, A/B testing etc. Those are neither standardized, proven to be valuable in a rigorous way, nor widely used. All signs of an immature industry. Further, they can only be used in software development processes that allow for iterative deployment.
As for surveys, KPIs, A/B testing etc. Those are neither standardized, proven to be valuable in a rigorous way, nor widely used. All signs of an immature industry. Further, they can only be used in software development processes that allow for iterative deployment.
I think its easy to judge if a software project was successful (eg. Did we launch? Did we deploy that feature?).
The harder question I suppose is whether it was successful and we've got/maintained a quality codebase.
The harder question I suppose is whether it was successful and we've got/maintained a quality codebase.
But compared to what? Most software continues to be bespoke/new work. If a different team/process was used would we have been as successful/spent as much money.
This touches on the classic question of "is coding engineering or art"? If it were engineering, it would become quantifiable once we have enough empirical data from previous projects to base our theories on. If it were art, that would be impossible since every project is as individual as the last one. It's probably inbetween.
Engineering is just applied science. And other engineering fields experience the same types of failure that software engineering experiences -- cost overruns, undefined requirements, unseen technical hurdles, etc.
that's the same by saying your kids are successful just because they were born.
"just because they were born"
Thats an example of a successful pregnancy project.
Thats an example of a successful pregnancy project.
Some good points but the argument that software teams will be most performant as a result of autonomy really depends on the team in question.
I worked on a small team with 2 other developers who were both pretty good devs technically. However they treated the business side with almost-contempt and they would estimate even simple changes to take days.
As the most junior member on the team I couldn't really influence them. Interestingly, after about 2/3 months on the job, the business side decided to use me as their initial go-to for dev.
I worked on a small team with 2 other developers who were both pretty good devs technically. However they treated the business side with almost-contempt and they would estimate even simple changes to take days.
As the most junior member on the team I couldn't really influence them. Interestingly, after about 2/3 months on the job, the business side decided to use me as their initial go-to for dev.
This stands as an interesting broad strokes story from a developer's experience at a growing company, but worth keeping in mind it's one specific scenario and one perspective on it.
In the generalizations-from-this-instance part of the essay, watch for two false dichotomies—"developers that care about getting things done fast with little technical debt and hate having PMs" vs "mercenary developers who like doing one small thing at a time without architecting things themselves, don't find fast ways to do things and ps like cars and money instead of hacking".
And "no PMs or process at all" vs "way too much process causing poor development time investment".
The best developers, team leads, PMs, etc know when to introduce new processes and team members and when not to. And, importantly, how to tailor processes to each team member to make them as effective as possible. And they work together collaboratively to solve problems—estimating and discussing features flexibly, not tossing pie in the sky specs and finished products over the fence.
In this instance it sounds like they didn't do a great job of working with existing scrappy developers' potential, but instead supplanted a new framework (eng/PM) they had seen work before, and the blunt hammer of that move destroyed a lot of potential the early team had invested in. It sounds like there was a general communication issue that was crippling the team even before a producer and new hires came in.
I've seen a few teams now grow from no dev process to combinations of issue trackers, estimates, specs etc. Around 14-20 developers it becomes nearly inevitable for someone to take on a high level production role and someone to take point for engineering reliability, whether those are official job titles or not.
Often this period coincides with when early team members move on. It's rad when growing companies find ways to keep those early, scrappy hires with deep historical product knowledge in productive roles as the company grows and shifts priorities from staff-leanness and product-speed to staff-scale and product-predictability. But that's often unfortunately not what happens, and it can be extremely painful for both early team members and those trying to evolve the company. (Growing pains!)
In the generalizations-from-this-instance part of the essay, watch for two false dichotomies—"developers that care about getting things done fast with little technical debt and hate having PMs" vs "mercenary developers who like doing one small thing at a time without architecting things themselves, don't find fast ways to do things and ps like cars and money instead of hacking".
And "no PMs or process at all" vs "way too much process causing poor development time investment".
The best developers, team leads, PMs, etc know when to introduce new processes and team members and when not to. And, importantly, how to tailor processes to each team member to make them as effective as possible. And they work together collaboratively to solve problems—estimating and discussing features flexibly, not tossing pie in the sky specs and finished products over the fence.
In this instance it sounds like they didn't do a great job of working with existing scrappy developers' potential, but instead supplanted a new framework (eng/PM) they had seen work before, and the blunt hammer of that move destroyed a lot of potential the early team had invested in. It sounds like there was a general communication issue that was crippling the team even before a producer and new hires came in.
I've seen a few teams now grow from no dev process to combinations of issue trackers, estimates, specs etc. Around 14-20 developers it becomes nearly inevitable for someone to take on a high level production role and someone to take point for engineering reliability, whether those are official job titles or not.
Often this period coincides with when early team members move on. It's rad when growing companies find ways to keep those early, scrappy hires with deep historical product knowledge in productive roles as the company grows and shifts priorities from staff-leanness and product-speed to staff-scale and product-predictability. But that's often unfortunately not what happens, and it can be extremely painful for both early team members and those trying to evolve the company. (Growing pains!)
Great article, this echoes a lot of my frustrations working in the software world. It doesn't help that I've experienced being on a well-managed software team working on interesting problems--it kinda spoiled me for all those other jobs... :)
Anybody have any advice for escaping this? I want the freedom to work on interesting things in my own way with a minimum of the politics. Ideally a PM would be someone who pushes back on all this micromanagement crap and does everything they can to make the developers' jobs easier. It seems I'm not self-motivated enough to do freelance work or start a start-up, so what other options are there?
Anybody have any advice for escaping this? I want the freedom to work on interesting things in my own way with a minimum of the politics. Ideally a PM would be someone who pushes back on all this micromanagement crap and does everything they can to make the developers' jobs easier. It seems I'm not self-motivated enough to do freelance work or start a start-up, so what other options are there?
It sounds like you were at a company you enjoyed before—are they still hiring? :P
If not, maybe you can do another job search and try to select for companies that manage their projects how you'd prefer. Try asking team members what the process is like and how they feel about it. Often times those Qs are more illuminating than ones about the software stack.
If not, maybe you can do another job search and try to select for companies that manage their projects how you'd prefer. Try asking team members what the process is like and how they feel about it. Often times those Qs are more illuminating than ones about the software stack.
Ah the "lets make the project cooler by adding a DSL so customers can add their own features!" never ever pans out! ;)
I spent the 90s working on office automation projects that always seemed to degenerate into report DSLs. Is nothing new?
The better I get at coding the more I am attracted to avoiding complicated tooling.
I spent the 90s working on office automation projects that always seemed to degenerate into report DSLs. Is nothing new?
The better I get at coding the more I am attracted to avoiding complicated tooling.
So a project was "months" behind schedule, they implemented an agile process for tracking tasks, and "everything slowed"? Slower than what? Being months behind schedule?
I get that some PMs can undervalue refactoring code / minimizing technical debt, and that's super frustrating and shortsighted. But the basic premise of this criticism of agile process is deeply flawed:
1. The claim that features took "longer" to ship is directly contradictory to the admission that the project was months behind schedule.
2. If they were behind schedule, then "inflating" their estimates in response to a detailed tracking process was not, in fact, an inflation. It was a reality check.
Estimates are really hard. But the solution is not to just "give autonomy" with zero estimation, because that's how you get into that problem they had in the first place: a guy in a room that doesn't ship for months. That's why agile's approach of breaking things down into tasks with very rough sizing and measuring actual after-the-fact time and shipping small milestones frequently is so helpful. You don't have to have super accurate estimates. You just need to report your time and then it figures out a team "velocity". That helps teams be more predictable, which is what it means to be professional and deliver things to customers on time.
I get that some PMs can undervalue refactoring code / minimizing technical debt, and that's super frustrating and shortsighted. But the basic premise of this criticism of agile process is deeply flawed:
1. The claim that features took "longer" to ship is directly contradictory to the admission that the project was months behind schedule.
2. If they were behind schedule, then "inflating" their estimates in response to a detailed tracking process was not, in fact, an inflation. It was a reality check.
Estimates are really hard. But the solution is not to just "give autonomy" with zero estimation, because that's how you get into that problem they had in the first place: a guy in a room that doesn't ship for months. That's why agile's approach of breaking things down into tasks with very rough sizing and measuring actual after-the-fact time and shipping small milestones frequently is so helpful. You don't have to have super accurate estimates. You just need to report your time and then it figures out a team "velocity". That helps teams be more predictable, which is what it means to be professional and deliver things to customers on time.
Yet agile implemented top-down without team ownership of what to work on is not agile and not good for the health of the codebase. I have seen it fail repeatedly.
Basically, if your team is skilled and capable, the process is not that important, as they will find a way to get things done. If the team is not good, the process won't make them much better. The key to a smoothly performing software dev team is good hiring and good coaching.
Basically, if your team is skilled and capable, the process is not that important, as they will find a way to get things done. If the team is not good, the process won't make them much better. The key to a smoothly performing software dev team is good hiring and good coaching.
So if you're behind schedule, your team just isn't skilled enough? That's kind of a dodge. Every team can improve.
Instead of exclusively focusing on finding "good" developers, let's also focus on evolving "good" process. Time tracking, estimates, itemizing tasks.. these are in fact good things.
Instead of exclusively focusing on finding "good" developers, let's also focus on evolving "good" process. Time tracking, estimates, itemizing tasks.. these are in fact good things.
I would, and have, argue that estimates and time tracking are, in general, wasted effort.
If you have good priorities, estimates are irrelevant, because you'll be working on the most important things, and that is unlikely to change no matter the estimated effort. If you don't have estimates, then you don't need time tracking to see if your estimates are correct.
You've just eliminated half of the overhead for software development - the only added cost is that you must continually understand and update your priorities (or values, if you prefer), which you should be doing anyway.
If you have good priorities, estimates are irrelevant, because you'll be working on the most important things, and that is unlikely to change no matter the estimated effort. If you don't have estimates, then you don't need time tracking to see if your estimates are correct.
You've just eliminated half of the overhead for software development - the only added cost is that you must continually understand and update your priorities (or values, if you prefer), which you should be doing anyway.
Sometimes I feel JIRA is the manna (http://marshallbrain.com/manna1.htm) for software developers :(
Not 100% convinced by the conclusion. There is good project management which can be relatively fine grained, but it doesn't have to be micromanagement and it doesn't have to be a death march.
There are some basic red flags raised:
> Our project manager would be displeased when tasks took longer than the estimate and would immediately assign one of the other team members to work with the original developer to hurry it along.
Shouldn't happen just at the whim of the PM. A sane environment would work by a developer asking for help first, and it actually sounds odd that you have capacity for a PM to throw someone to just 'hurry up' tasks
> Whenever there was any debate about refactoring the code, or backing out of a problematic feature, the new guys would argue against it, saying it was ‘ivory tower’, and not delivering features. The PM would veto the work...
Why does the PM have a veto? No technical lead or management with balls? PM's need to manage the features of a release and changes to the plan. Any PM who says features are set in stone isn't doing their job. A PM's role is to handle change and execute the plan. Sounds like weak management.
There are some basic red flags raised:
> Our project manager would be displeased when tasks took longer than the estimate and would immediately assign one of the other team members to work with the original developer to hurry it along.
Shouldn't happen just at the whim of the PM. A sane environment would work by a developer asking for help first, and it actually sounds odd that you have capacity for a PM to throw someone to just 'hurry up' tasks
> Whenever there was any debate about refactoring the code, or backing out of a problematic feature, the new guys would argue against it, saying it was ‘ivory tower’, and not delivering features. The PM would veto the work...
Why does the PM have a veto? No technical lead or management with balls? PM's need to manage the features of a release and changes to the plan. Any PM who says features are set in stone isn't doing their job. A PM's role is to handle change and execute the plan. Sounds like weak management.
> Shouldn't happen just at the whim of the PM. A sane environment would work by a developer asking for help first, and it actually sounds odd that you have capacity for a PM to throw someone to just 'hurry up' tasks
The problem is that if the PM decides to do that, the developer has no authority to refuse that.
> Any PM who says features are set in stone isn't doing their job. A PM's role is to handle change and execute the plan. Sounds like weak management.
Most PMs are just proxies for business, they manage up and out but not down. They will not risk their jobs by refusing requests from business, in the long term that would put them in an unsustainable position.
The problem is that if the PM decides to do that, the developer has no authority to refuse that.
> Any PM who says features are set in stone isn't doing their job. A PM's role is to handle change and execute the plan. Sounds like weak management.
Most PMs are just proxies for business, they manage up and out but not down. They will not risk their jobs by refusing requests from business, in the long term that would put them in an unsustainable position.
Maybe at some companies. Where I work, Engineering Managers and PMs are totally separate. So Engineers have much more representation.
But, even in places where this is not the case, they are willing to hire-- spend money - - to speed the project up. If it's made clear, not just to the PM, that it's going to cost money and have no positive effect, it should be a clear business decision.
But, even in places where this is not the case, they are willing to hire-- spend money - - to speed the project up. If it's made clear, not just to the PM, that it's going to cost money and have no positive effect, it should be a clear business decision.
> Maybe at some companies. Where I work, Engineering Managers and PMs are totally separate. So Engineers have much more representation.
Exactly!
Exactly!
The moral of this story is that "let's create a DSL so that users can encode their business logic" is jumping the shark. I was mildly disappointed that the hero of this tale (the PM) didn't fire the "DSL guy" on day one
DSLs for stakeholders aren't always bad. DSLs thrown over the fence without early and regular stakeholder testing are usually bad though :)
The more projects that I've shipped from conception to completion, the more I'm believing that there are two fundamental phases for each project, and you need radically different management philosophies for each.
Phase 1 is "will it work?" You get a vaguely-specified business requirement, maybe some intuition that a market could be better served by software. And your job is to build that software, and figure out exactly what's required for it.
In phase 1, you need the creative-genius programmers, and they need to work in small teams with large amounts of autonomy. Because most of what goes on in phase 1 is failure: you are learning about the problem space and all of its corner-cases, you're trying out different approaches, and you're hoping to make that one creative leap that brings everything together. Prototyping is invaluable, refactoring is important, and deadlines and estimates might as well be plucked out of thin air. To successfully run a phase 1 project, you often need to be able to redefine success. When I read the article, my first impulse was to say "Well, the biggest fuckup management made was to not cancel the feature, because they had ample evidence that this feature was not worth the cost." A startup's entire life is spent in phase 1, because once it's exited phase 1 it's called a "high-growth company", and their version of redefining success is the pivot.
Phase 2 is "make it work". You start phase 2 with a working prototype that demonstrates the feasibility of what you're hoping to do, but still has a lot of rough edges. And your job is to polish it down to something that the customer wants to use daily. That means fixing bugs, improving usability, adding admin tools & logging, improving performance and reliability, ensuring security, etc.
In phase 2, you need a much larger team of disciplined, detail-oriented engineers. Because debugging can be parallelized. You need unit tests, you need formal processes, you need issue trackers, you usually need PMs or management. It helps to break things into user stories so that you know you're always making progress.
I see a fair amount of hate for Agile and Scrum on HN, but these are tools, and specifically tools for Phase 2 work. I use them myself, for my own projects, because I find that they help me manage all the little tasks involved in bringing a product to market. The hate comes from people who misapply them: startups who have big-company management who blindly apply what worked at their last employer, or established companies that are trying to do new green-field projects and believe it works the same way improving your 10-year-old product works. But similarly, there are a large number of abandoned startups and open-source projects that never bothered to cross the Ts and dot the Is, and so are largely useless to people.
Phase 1 is "will it work?" You get a vaguely-specified business requirement, maybe some intuition that a market could be better served by software. And your job is to build that software, and figure out exactly what's required for it.
In phase 1, you need the creative-genius programmers, and they need to work in small teams with large amounts of autonomy. Because most of what goes on in phase 1 is failure: you are learning about the problem space and all of its corner-cases, you're trying out different approaches, and you're hoping to make that one creative leap that brings everything together. Prototyping is invaluable, refactoring is important, and deadlines and estimates might as well be plucked out of thin air. To successfully run a phase 1 project, you often need to be able to redefine success. When I read the article, my first impulse was to say "Well, the biggest fuckup management made was to not cancel the feature, because they had ample evidence that this feature was not worth the cost." A startup's entire life is spent in phase 1, because once it's exited phase 1 it's called a "high-growth company", and their version of redefining success is the pivot.
Phase 2 is "make it work". You start phase 2 with a working prototype that demonstrates the feasibility of what you're hoping to do, but still has a lot of rough edges. And your job is to polish it down to something that the customer wants to use daily. That means fixing bugs, improving usability, adding admin tools & logging, improving performance and reliability, ensuring security, etc.
In phase 2, you need a much larger team of disciplined, detail-oriented engineers. Because debugging can be parallelized. You need unit tests, you need formal processes, you need issue trackers, you usually need PMs or management. It helps to break things into user stories so that you know you're always making progress.
I see a fair amount of hate for Agile and Scrum on HN, but these are tools, and specifically tools for Phase 2 work. I use them myself, for my own projects, because I find that they help me manage all the little tasks involved in bringing a product to market. The hate comes from people who misapply them: startups who have big-company management who blindly apply what worked at their last employer, or established companies that are trying to do new green-field projects and believe it works the same way improving your 10-year-old product works. But similarly, there are a large number of abandoned startups and open-source projects that never bothered to cross the Ts and dot the Is, and so are largely useless to people.
The more projects I work on the more I am convinced most projects are a combination of phase 1 and phase 2 work.
The biggest problem I see is projects usually adopt a one sized fits all approach.
If part of the team is using a strict scrum process and they find it helpful because they are doing phase 2 work then all of the team gets forced into it even if they are doing phase 1 work etc.
The biggest problem I see is projects usually adopt a one sized fits all approach.
If part of the team is using a strict scrum process and they find it helpful because they are doing phase 2 work then all of the team gets forced into it even if they are doing phase 1 work etc.
There's no "Heisenberg" here - the company decided to do the moral equivalent of invading Russia in the winter. I quote - "Then came that requirement. The one where you try to replace an expert user’s years of experience and intuition with software."
The only problem with "finely grained management" is that it costs too much.
The only problem with "finely grained management" is that it costs too much.
About processes:
You add a process when you want repeatable results.
Adding blocking, synchronous steps involving people slows things down. Adding non-blocking, asynchronous, tool assisted steps are less intrusive in people's work.
About hierarchies: You add hierarchies in your organization when your quorum involves too many people and things slow down. Hierarchies exist to make consensus building simpler at the cost of representing fewer people and all the associated consequences. Hierarchy must not be abused. People need to be respectful towards others regardless of hierarchy. Each contributor is important.
About quality and technical debt: If you are always reacting to defects, you lost control of your product. You can no longer plan because you are too busy reacting to ad-hoc unplanned work. This is unprefessional and unnecessary. Keep things under control by being preventive, proactive and professional. If someone tries to convince you that non-functional requirements cannot be sold, remember that person that person to focus on functional requirements and leave the non-functional requirements to the engineers.
About hierarchies: You add hierarchies in your organization when your quorum involves too many people and things slow down. Hierarchies exist to make consensus building simpler at the cost of representing fewer people and all the associated consequences. Hierarchy must not be abused. People need to be respectful towards others regardless of hierarchy. Each contributor is important.
About quality and technical debt: If you are always reacting to defects, you lost control of your product. You can no longer plan because you are too busy reacting to ad-hoc unplanned work. This is unprefessional and unnecessary. Keep things under control by being preventive, proactive and professional. If someone tries to convince you that non-functional requirements cannot be sold, remember that person that person to focus on functional requirements and leave the non-functional requirements to the engineers.
I've worked for companies like this. What's hilarious is that most of the employees at these companies take the process very seriously (they obviously don't know better). I've worked at both startups and big companies - I find that fine-grained management in big companies is extremely inefficient. In software, the more constraints you add to a project, the slower things will progress.
It gives non-technical managers extra visibility at the cost of speed and agility.
I can't help but chuckle to myself whenever we have a 'retrospective meeting' - Every single time, it's the same problems that come up over and over again (related to management/communication issues) and these problems never get fixed.
What's even funnier is that the closer we get to a deadline, the more meetings we have - And the more it slows us down.
There is a fundamental problem with having very fine-grained cards/stories/tasks; often, related tasks are assigned to different people but it would have been much more efficient to assign all these tasks to a single person.
It gives non-technical managers extra visibility at the cost of speed and agility.
I can't help but chuckle to myself whenever we have a 'retrospective meeting' - Every single time, it's the same problems that come up over and over again (related to management/communication issues) and these problems never get fixed.
What's even funnier is that the closer we get to a deadline, the more meetings we have - And the more it slows us down.
There is a fundamental problem with having very fine-grained cards/stories/tasks; often, related tasks are assigned to different people but it would have been much more efficient to assign all these tasks to a single person.
>>> It gives non-technical managers extra visibility at the cost of speed and agility.
Keen observation. Often times these situations are just self-inflicted wounds on the part of devs too. I have worked with many devs that have had a habit of keeping stakeholders and coworkers in the dark just because they feel like they are too important to be bothered/be held accountable.
I know what I'm in for if a project management or glass house CIO is all of the sudden needed, so my top priority is always to primarily earn the trust of business stakeholders and to be as honest as possible.
Keen observation. Often times these situations are just self-inflicted wounds on the part of devs too. I have worked with many devs that have had a habit of keeping stakeholders and coworkers in the dark just because they feel like they are too important to be bothered/be held accountable.
I know what I'm in for if a project management or glass house CIO is all of the sudden needed, so my top priority is always to primarily earn the trust of business stakeholders and to be as honest as possible.
> It gives non-technical managers extra visibility at the cost of speed and agility.
Hmm, just like with tracing. The more finegrained tracing, the more resources are used for communicating what you do and less resources are going into actual doing. Developers understand this, managmenet may not. Management IS about communicating, so they try to "Do Something" and enforce more communication.
Hmm, just like with tracing. The more finegrained tracing, the more resources are used for communicating what you do and less resources are going into actual doing. Developers understand this, managmenet may not. Management IS about communicating, so they try to "Do Something" and enforce more communication.
Ever work with an engineering team? Building new weapons systems? Fighter planes and the like? Just as creative an endeavor if not more so than software development yet they have schedules and budgets to meet too. And yet people's lives depend on the result. Software development can learn a lot from other engineering disciplines.
Software dev isn't driving this, business is. NASA coding practices prove we can do exactly what you're saying, but businesses don't care for (or don't often need) the rigor that NASA requires. I'd bet a lot of people would enjoy participating in NASA-quality projects if only to experience it and feel good about producing rock-solid code even if they only commit 50 lines total, but they are very rare.
I feel like you might have missed the point. Also you're assuming these engineering teams for weapons systems and fighter planes are successful by default.
F-35?
F-35?
Not all engineering projects are successful either. What I'm saying is there's a lot of similarities between these disciplines and so there exists a large body of knowledge and experience from which we can cull and learn.
The author described two perfectly good responses for this scenario, and managed to paint them both as the cowards path. Leaving the company, and checking out mentally, letting the people with the responsibility hang themselves with their own rope. The company is bigger than you are, its decisions weigh heavier than yours. Stop with the ego-belief that you know better than it. It's cold comfort to be right, so just get behind management and try to make the new direction work.
I mean, come on, in the grand scheme of things, developers are wizards who never have to be worried about 90% of the things other people in the world have to worry about. These finer qualities of career enjoyment are nice-to-haves, not necessities. There's always good, solid ground to retreat to in case you get routed. Complaints like this remind me of a rich wanker bitching about the valet not putting his seat back the way he left it. Just adjust it yourself and move on with life. Life's too short to get mad about stuff like that.