Great advice! I would agree with everything except maybe that “I just had to hack something together…” always is a bad thing.
Especially from the business point of view this article stresses, it can be reasonable to 80/20 your way out of certain problems and then polish it in the future.
As well as your average customer. Your average customer couldn't care less about the maintainability, testability, or cleanliness of the code. They care about getting the features they asked for within the time frame they were promised for the price they were quoted. You could argue that those things all play into that and are things they should care about and I wouldn't disagree. But the reality is they don't. If you tell them you have to push it back because you need to clean up the code and make it look pretty you're going to have an unhappy customer.
The problem with the "Don't hack things together" advice is that it's invariably written by developers who like to write code, enjoy writing about code, and want to be seen as thoughtful and influential people in their development community. Those sorts of people tend to gravitate towards the projects that have the scale where code quality is critical because what they work on lasts for years with thousands of people building on it.
If you're a developer who throws code together in a few months for clients who aren't paying for a quality product, and maybe you'll come back to it a couple of times in the future when it needs a new field added or a page title changed, then a hack is perfectly valid and can hugely improve your business's bottom line over spending even just another 10% making sure you've got tests and documentation and defensive code and so on. Spending time on the maintainability of code that no one will ever maintain is a waste of time.
Thanks for this comment. I kind of feared saying something like this would be begging for down votes, but I'm glad I'm not alone. I truly believe that a good developer knows how to strike a balance, and if he/she wants to be a hero to the team, sometimes a hack is better than stressing out 4 other people because you are insistent about adhering to an architectural pattern in the face of a looming and important deadline.
This has been a major point of contention for us recently with team members that can't distinguish 'urgent' matters from 'important' ones.
"Some organizations pretend that they are about other things, like serving people or changing the world. But in truth they are measured by money."
And in practice they rarely are not. Nobody calculates the total cost of an unnecessary two hour meeting where 8 highly-paid employees discuss about something almost completely irrelevant.
Another problem with this is that it's extremely difficult to calculate anything when it comes to software, so expenses and profits are usually created using Stetson-Harrison when some higher-up needs a budget.
In fact, I'd say that companies that don't have such an "accounting" focus on software development do a lot better.
"And in practice they rarely are not. Nobody calculates the total cost of an unnecessary two hour meeting where 8 highly-paid employees discuss about something almost completely irrelevant."
In my experience, that is absolutely not true. Just about any meeting I've ever been in with more than 6 people, the very first question was, "this meeting is expensive, does it need to happen and do we need everyone?"
Sounds like a good place to work. But that's in no way typical. At every place I've worked (granted, not all that many) meetings are "free" and when you don't want to be at the meeting you're "not being a team player."
Whenever I tell recruiters or career councilors that I am looking for 'junior developer' jobs they look at me like I am crazy, like such things don't exist and that I don't and to work hard or do real software development. So it is nice to know a decade after getting a Computer Science degree that such jobs may actually exist.
I really don't agree with the final "Present a solution, not just a problem" point. Quite often a developer will be able to see a problem but won't have a clue what the solution is. Having a "Present a solution, not just a problem" approach means that developers won't want to inform you that the problem is there, and then it'll surprise you later at the worst possible time. If you have a solution, great. If you don't, also great. But always communicate a problem exists.
Agree with your point that quite often a dev might not have a solution. Seeking help should of course be encouraged, but one must also put in some thought for a solution. I think the author had extensive cases of trigger happy devs always coming to him with problems. As dev-s, you should be able to think with different perspectives and not simply go to your manager with the first instance of a problem.
I am not disagreeing with your reading of the article, but adding on my own interpretation, as this general advice is tossed around on multiple teams I work with.
The way I see this is not as a diktat, but as an acknowledgement that if you find a problem, you have enough domain knowledge to be able to contribute to a solution, and the fact that you are the first to identify the problem lends evidence to support the fact that you understand (at least a portion of) the source of the problem better than your team.
Don't pass the buck by reporting the problem and assuming it will be fixed. Take the time to fix it to improve things for you and for your team.
Obviously there is a huge range of appropriate responses, but I think keeping this sort of understanding is important. A problem that you identify is a problem in something that at least touches your team's primary responsibility.
I'd modify it to "Don't present just a problem, present a solution, or all the solutions you've tried and why they didn't solve the problem."
I've also heard some companies have time limits on seeking help, e.g. if you're a junior developer and can't solve the problem on your own within 15 minutes, ask for help.
I encourage the 15 minute rule, but not to just ask help from anyone. Another difficult thing to accomplish as a manager is to prevent unnecessary interruptions for anyone on my team. In an ideal scenario all that stuff goes through me. Not because I want that control. It's because I have the responsibility. One of those responsibilities is to get the most out of my team. So if that means interrupt me instead of your teammates that's my preference pretty much 100% of the time, unless I'm unavailable.
Having managed teams before, my feeling is that this advice is good in some cases, and bad in others.
For example, if your team is filled with a bunch of newbies who don't really know what they're capable of yet, their default reaction alot of times is to come to you with their issue. If it happens too frequently it can become counter-productive.
On the other hand, some problems can take a long time just to figure out what's going on, and even more it can be difficult to articulate the issue precisely. As long as the problem is well formulated and precise, progress can usually be achieved by bringing the problem (without solution).
Generally speaking, though, it's good to keep in mind that a manager usually has a ton on his plate already and needs to deal with all his team's problems, whereas the developer is only responsible for working on the one problem.
Final point would be that, especially with younger devs, they can get into a "paralysis by analysis" state. I encourage younger devs to not work on a problem for too long so they're not spinning their wheels. So in these cases I want my younger devs to come to me after they've spent maybe 10-15 minutes on a problem, even if at the end they still don't know what the problem is.
Nice writeup, with the exception that you should never, ever "love something so much you'd do it for free" in a professional setting. I get that the intention behind the statement isn't literal, but that kind of attitude is what makes hiring managers think that they can make junior developers sub-25k offers in places like Manhattan.
I had the confidence to never allow myself to be low balled and quite enjoyed the lectures about "paying my dues" and "being thankful to have an offer in this field/economy" - the looks on their faces when I still rejected the offer doubly so. But not every hopeful developer has that.
In addition, it pushes company culture to use passion as a hiring signal, discriminating against developers who do not show sufficient levels because they are not "good". In my opinion, this leads to both the so-called "talent shortage" we have now and the underrepresentation of certain groups in the industry.
There are far more developer jobs than there are "passionate" developers. Many developer jobs that need doing are partially or totally a slog that no one would be expected to love.
This is definitely true. I've been labeled on occasion as "not passionate" for not being willing to work myself into the ground at 60+ hours a week with a four hour round trip commute.
That's not to say that I won't work long hours at crunch time or I have a problem with going the extra mile. But if your "crunch time" is 52 weeks a year, it's no longer a matter of passion, it's just exploitative.
This is going to come off extremely cynical but this post intersects at 2 points that interest me. One being advice I would give to my former self, and the other is how I as a person fit into the business world.
The post makes a simple yet important observation:
> That business is measured by a very simple equation: revenues minus expenses equals profit.
For those of you starting out it may not be obvious to you that there are VERY well paid people whose sole job it is is to look at the expenses column and figure out ways to shrink it. With that in mind you should understand that if you work at a technology company YOU and your fellow developers are the biggest expense. Plan accordingly.
The developers at a software company are considered an expense but a required expense due to them creating the products that bring the revenue in. Shrinking the expenses by shrinking the developer count occurs but I would think that would have an impact later on the amount of revenue that could potentially be generated.
In a non-tech company I agree with your statement. Likely the revenue is brought in through some other avenue. A developer in that scenario is defiantly seen as more of an expense to reduce.
Every expense is a required expense. Every expense is looked at to be minimized. They're going to run with the fewest, cheapest developers as they think they can get away with to deliver what they want to deliver on the schedule they want to deliver it. It doesn't always work like that, over time bloat accumulates leading to restructuring/layoffs. This is so standard that exceptions are notable (20% time, skunkworks, etc...)
Totally agree with the point about Learning to Communicate.
Have seen the 'rock-star senior devs' think and speak so clearly with a variety of audience, and on the other hand 'just-the senior devs' who struggle explaining what they want to put across. Coding and communication should be complementing each other, as both have their roots in 'what you think'.
A lot of this is really wonderful advice, though I disagree somewhat on one point.
The good stuff first - I completely agree that a developer should look at a maintenance project as a learning opportunity. I was lucky enough to get a lot of researchy, green field projects early in my career. But I grew a lot as a developer when I started maintaining, adapting, and modifying an existing code base. My only real caveat here is that it should be a relevant project, ideally an open source project. You'll be introduced to a lot of different developers, and you'll get a really good sense of how to work collaboratively with a lot of different people. There is a huge difference between a project that says "there's an existing open source app - it's reasonably well written, but it needs work and updating, and we need some new features" and "here's stan's old pile of crap, keep it running." The first can be a huge learning experience and great for building a network and career. This is the sort of experience that gets you to a point where you may be able to get new programming jobs without 3 references and several hours at the whiteboard showing how to find a cycle in a linked list. A lot of people know you because they have worked with you, and they know your code because, well, they've reviewed your code and you've reviewed theirs. It really is a way to rise above some of the unpleasantness of our industry.
Now for my disagreement. "Do this job because you love it." I'd be ok if we added the phrase "as the thing you do for money." I don't think you need to love programming so much that you'd do it even if you suddenly had 10 mil in your bank account. That may be an unrealistic standard.
32 comments
[ 2.6 ms ] story [ 68.5 ms ] threadEspecially from the business point of view this article stresses, it can be reasonable to 80/20 your way out of certain problems and then polish it in the future.
If you're a developer who throws code together in a few months for clients who aren't paying for a quality product, and maybe you'll come back to it a couple of times in the future when it needs a new field added or a page title changed, then a hack is perfectly valid and can hugely improve your business's bottom line over spending even just another 10% making sure you've got tests and documentation and defensive code and so on. Spending time on the maintainability of code that no one will ever maintain is a waste of time.
This has been a major point of contention for us recently with team members that can't distinguish 'urgent' matters from 'important' ones.
And in practice they rarely are not. Nobody calculates the total cost of an unnecessary two hour meeting where 8 highly-paid employees discuss about something almost completely irrelevant.
Another problem with this is that it's extremely difficult to calculate anything when it comes to software, so expenses and profits are usually created using Stetson-Harrison when some higher-up needs a budget.
In fact, I'd say that companies that don't have such an "accounting" focus on software development do a lot better.
In my experience, that is absolutely not true. Just about any meeting I've ever been in with more than 6 people, the very first question was, "this meeting is expensive, does it need to happen and do we need everyone?"
And I worked at really small and really big companies.
No one thought about the cost of a meeting, they thought of them as a normal thing every company does for a few hours a week.
The way I see this is not as a diktat, but as an acknowledgement that if you find a problem, you have enough domain knowledge to be able to contribute to a solution, and the fact that you are the first to identify the problem lends evidence to support the fact that you understand (at least a portion of) the source of the problem better than your team.
Don't pass the buck by reporting the problem and assuming it will be fixed. Take the time to fix it to improve things for you and for your team.
Obviously there is a huge range of appropriate responses, but I think keeping this sort of understanding is important. A problem that you identify is a problem in something that at least touches your team's primary responsibility.
I've also heard some companies have time limits on seeking help, e.g. if you're a junior developer and can't solve the problem on your own within 15 minutes, ask for help.
For example, if your team is filled with a bunch of newbies who don't really know what they're capable of yet, their default reaction alot of times is to come to you with their issue. If it happens too frequently it can become counter-productive.
On the other hand, some problems can take a long time just to figure out what's going on, and even more it can be difficult to articulate the issue precisely. As long as the problem is well formulated and precise, progress can usually be achieved by bringing the problem (without solution).
Generally speaking, though, it's good to keep in mind that a manager usually has a ton on his plate already and needs to deal with all his team's problems, whereas the developer is only responsible for working on the one problem.
Final point would be that, especially with younger devs, they can get into a "paralysis by analysis" state. I encourage younger devs to not work on a problem for too long so they're not spinning their wheels. So in these cases I want my younger devs to come to me after they've spent maybe 10-15 minutes on a problem, even if at the end they still don't know what the problem is.
I had the confidence to never allow myself to be low balled and quite enjoyed the lectures about "paying my dues" and "being thankful to have an offer in this field/economy" - the looks on their faces when I still rejected the offer doubly so. But not every hopeful developer has that.
There are far more developer jobs than there are "passionate" developers. Many developer jobs that need doing are partially or totally a slog that no one would be expected to love.
That's not to say that I won't work long hours at crunch time or I have a problem with going the extra mile. But if your "crunch time" is 52 weeks a year, it's no longer a matter of passion, it's just exploitative.
The post makes a simple yet important observation:
> That business is measured by a very simple equation: revenues minus expenses equals profit.
For those of you starting out it may not be obvious to you that there are VERY well paid people whose sole job it is is to look at the expenses column and figure out ways to shrink it. With that in mind you should understand that if you work at a technology company YOU and your fellow developers are the biggest expense. Plan accordingly.
In a non-tech company I agree with your statement. Likely the revenue is brought in through some other avenue. A developer in that scenario is defiantly seen as more of an expense to reduce.
Do I have a skewed mindset around this?
Every expense is a required expense. Every expense is looked at to be minimized. They're going to run with the fewest, cheapest developers as they think they can get away with to deliver what they want to deliver on the schedule they want to deliver it. It doesn't always work like that, over time bloat accumulates leading to restructuring/layoffs. This is so standard that exceptions are notable (20% time, skunkworks, etc...)
oooor bills to pay...
Will save you alot of time at work, and in life.
The good stuff first - I completely agree that a developer should look at a maintenance project as a learning opportunity. I was lucky enough to get a lot of researchy, green field projects early in my career. But I grew a lot as a developer when I started maintaining, adapting, and modifying an existing code base. My only real caveat here is that it should be a relevant project, ideally an open source project. You'll be introduced to a lot of different developers, and you'll get a really good sense of how to work collaboratively with a lot of different people. There is a huge difference between a project that says "there's an existing open source app - it's reasonably well written, but it needs work and updating, and we need some new features" and "here's stan's old pile of crap, keep it running." The first can be a huge learning experience and great for building a network and career. This is the sort of experience that gets you to a point where you may be able to get new programming jobs without 3 references and several hours at the whiteboard showing how to find a cycle in a linked list. A lot of people know you because they have worked with you, and they know your code because, well, they've reviewed your code and you've reviewed theirs. It really is a way to rise above some of the unpleasantness of our industry.
Now for my disagreement. "Do this job because you love it." I'd be ok if we added the phrase "as the thing you do for money." I don't think you need to love programming so much that you'd do it even if you suddenly had 10 mil in your bank account. That may be an unrealistic standard.