Letters to Junior Developers
codeovereasy.com
codeovereasy.com
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 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.
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 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...)
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.
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.
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.
oooor bills to pay...