41

I'm the only developer at a small company. I've slowly moved into development here; until ~4 months ago 50-75% of my time was spent on operations. Now, 50-75% of my time is spent on development, with the rest split between operations and various IT stuff. I regularly end up working 50+ hours a week.

I inherited some rather poorly-written applications (they were previously maintained by two people) that much of the business relies upon. Keeping these up and running, working on new, smaller applications, and my other responsibilities already take up all my time.

In order to be scalable, the existing software needs significant refactoring and additional functionality. I haven't had the pleasure to work on properly written or architected software before. The complexity of this task is well beyond anything I've done before (this is my first job out of college.) I know there's a feverish devotion to self-learning/learning by doing among many here, but this is so beyond my expertise that I wouldn't be doing my employer or myself any favors trying to tackle it alone.

I've been very direct about my inexperience, and in the past have mentioned that hiring another, more experienced developer will probably be necessary...if anything, just for the amount of time required for anyone to do the work as we grow and have more software to develop and maintain. I know that I would greatly benefit from hiring another developer; having someone to learn from and bounce ideas off of would be great. StackOverflow is great for determining approaches to individual coding problems or concepts, but is no replacement for discussions on a wider or more significant scale specific to a certain business domain. When mentioning hiring another developer in casual conversation recently, they didn't seem to think it was that important or necessary.

tl;dr: Current patch jobs and other responsibilities already take up all my time at work, work on existing applications that needs to be done is beyond my skillset, little chance of me having any time to work on new products that are being planned. Employer initially seems reluctant about hiring another developer.

How can I "sell" hiring another developer without sounding like I'm lazy or incompetent (I'd like to think I'm neither!)?

edit: Just wanted to clarify that I'm in no way interested in taking any kind of hostile action to prove a point (i.e. taking a vacation to show them they'd be screwed if I wasn't around.) I'm pretty content working here and consider myself to be fairly compensated, even figuring in the overtime, which is why I'm nowhere near considering a new job yet. That said, I accepted the 'no more overtime' answer - even if I don't mind working over too much I'm not doing anyone any favors by doing so (prone to more errors, wear myself out) and it's not really tenable in the short term much less the long term. I'll be stressing this when discussing the matter with my supervisor, and will probably suggest hiring a contractor part-time as an initial approach that's more financially palatable. Thanks for all the great answers.

gnat
  • 21,442
  • 29
  • 112
  • 288
John Straka
  • 2,313
  • 1
  • 22
  • 26
  • 6
    Out of curiosity, if you've never been able to, "work on properly written ... software before," then how do you know what good software looks like? (or for that matter, what bad software looks like?) – riwalk Sep 30 '11 at 15:13
  • 10
    These are all great suggestions but I have been in this boat before with small companies and the vast majority of them aren't concerned with the "what if I get hit by a bus?" argument and wouldn't address a problem like this until it becomes a critical disaster. If you want a long term career in software development then you are doing no good for yourself there. Get out. Go somewhere else where you can have a middle to senior level mentor who can help teach you and get you acclamated to large scary projects. This is exactly what I did and I never regretted it. – maple_shaft Sep 30 '11 at 15:20
  • 3
    @Stargazer712 - Probably the same way that any educated newbie finds out: Through books/blogs/screencasts from the best of the best developers in their respective language/platform. – Wayne Molina Sep 30 '11 at 15:25
  • @Stargazer712 - "I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description ["good software"]; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the code involved in this case is not that." - I may have taken some liberties with this quote. – John Straka Sep 30 '11 at 15:29
  • 2
    @Stargazer712, How do YOU know what "properly written" software looks like? He's having scaling problems and is overwhelmed with maintenance and feature implementation. This _can_ happen regardless of whether the codebase is good or bad. Getting some help is the right idea. – Angelo Sep 30 '11 at 15:44
  • @Angelo, everything I know has come through experience, and everything I don't know can be traced to a lack of experience. He seems to lack experience, thus my question. – riwalk Sep 30 '11 at 16:36
  • @Stargazer712 The experience of a senior developer is more irreplacable than hackneyed techniques gathered from online tutorials with no formal strategy. I'm in the same situation as him, looking for a work environment where young padawans can learn from seeing what *others* do at work. No doubt that it's good to know how to work independently, but you can't get the best experience just flying solo all the time. You get that by working with someone that can figuratively kick your a**. – Chris C Sep 30 '11 at 18:48
  • @CCRicers, I completely agree. But he has *none* of that, thus my question to him. – riwalk Sep 30 '11 at 18:50
  • 3
    @Stargazer712, no need to be very experienced to recognize bad code. Cryptic variable names, completely repetitive code, more commented out code than actual comments, no way to determine how a simple change will impact anything down the road, in-line SQL galore, nothing parameterized, no error handling, try-catch used for flow control everywhere, methods 1000s of lines long, completely procedural, uses goto (had no idea this existed in C#), deprecated code left in (not in separate methods.) Basically, it's a nightmare to make the slightest change. This is bad. – John Straka Sep 30 '11 at 19:09
  • @JohnStraka Okay you are right, that is BAD O_o! It could be worse though. When i got out of school my first task was to rewrite an old 8,000 line GW-BASIC program written for a Commodore 64 and littered with calculus equations for heat transfer. Variables where named individual letters and numbers and looping structures didn't even exist in this version of GW-BASIC when this was written so everything was cryptic labels and gotos. I actually took a bunch of physics and heat transfer books and studied for months before I could interpret the code. Fun times. Trust me, it could be worse. – maple_shaft Sep 30 '11 at 19:29

12 Answers12

68

I regularly end up working 50+ hours a week

To me thats all you need to tell your manager. "Im working 50+ hours a week to make sure the work gets done. Im a hard worker but this is unsustainable long term, you should hire another developer". If that dosent work then I suggest you start looking for a new job.

Tom Squires
  • 17,695
  • 11
  • 67
  • 88
  • 57
    Also, start by **NOT** working 50+ hours. Stop at the 8th hour each day. No reason to burn yourself out, especially if this is your first job out of college. 50+ hours a week is **not** normal, and never should be. – Wayne Molina Sep 30 '11 at 15:10
  • 4
    @WayneM, Yeah I have to agree, you are fresh out of college. The only reason you would be working that hard as a junior developer is if your boss is being cheap and taking advantage of you. 50+ hours a week is normal every once in a while but if its a habit then you are getting bilked. – maple_shaft Sep 30 '11 at 15:30
  • 2
    Suggestion: if the cheapskate has the nerve of implying you should keep up that insane schedule tell him the doctor told you not to. Mumble around something about work related illnesses whatever, no boss want to be found liable of anything like that. Anyway, probably there isn't enough money for a second dev... and he'll downsize operations. That means he'll stop going out selling and will slack off around the office pretending he's doing stuff. – ZJR Sep 30 '11 at 15:37
  • 7
    @ZJR I disagree. You shouldent make excuses for not wanting to do something unreasonable. – Tom Squires Sep 30 '11 at 15:47
  • I actually agree with your disagreeing, but some people are dense, some are shy. Are you gonna change everybody into a bold, reasonable, hero? I'm all about that. But I'm too lazy and I will adapt to live in the present, shoddy, times. (and if the guy is shy and his boss dense, he now has more ammo) :) – ZJR Sep 30 '11 at 15:54
  • OP dosent sound dense to me. – Tom Squires Sep 30 '11 at 15:58
  • What we also don't know is if the OP is being paid fairly for the 50+ hours. Some bosses seem to think the value of programmers is always based on what they quote a project to be worth, but there's a market for professional skills, and your worth is mostly based on that, and not simply on what he decides to pay you. – Chris C Sep 30 '11 at 18:53
  • 1
    @Wayne M - Just stopping doing overtime is likely to be bad advice. If they don't want to take on new staff, they may be prepared to sack someone and replace them with someone who will work 50 hour weeks every week, we don't know. Much better is to try and negotiate a better working arrangement, as Tom suggests and fall back to unilaterally cutting your hours if the negitiations fail or go on too long. I was once told point blank that if I wasn't working at least 8 hours overtime, I wasn't *pulling my weight*. My reaction was a work to rule, and I stayed that way until that manager left. – Mark Booth Sep 30 '11 at 19:48
  • 1
    If they'd be behind 10hrs/week because he's not working overtime, that means they'd be behind 300+ hours on development if they fire him and take a month and a half to find someone new (and that doesnt count any ramp-up time getting the new guy up to speed, which may be many more months of lost productivity). He's actually in a strong negotiating position. He doesnt have to make drama over it - just subtly start leaving earlier because he has other places to be. – GrandmasterB Oct 01 '11 at 03:44
27

I've been in a similar boat. A very similar boat. The one thing that really helped me make the "we need to expand the team" argument stick was how high our bus factor was -- if I got hit by one, there was no one who had any clue about the entire stack we relied upon. Getting someone else on the team was crucial for operations if nothing else.

Wyatt Barnett
  • 20,685
  • 50
  • 69
  • 8
    I like to refer to it as the "winning the lottery" factor. What if I win 300 million dollars in the lottery... Who's going to work on the systems? (I'll be in Hawaii, on the beach, drunk.) – Christopher Mahan Sep 30 '11 at 15:31
  • 7
    @ChristopherMahan I prefer the bus argument because you got a better chance of getting hit by a bus than winning 300 million dollars in the lottery :) – maple_shaft Sep 30 '11 at 15:33
  • This is something I will emphasize...probably a better approach than saying I eventually want to be able to actually use my PTO. – John Straka Sep 30 '11 at 15:36
  • 2
    I just started taking my PTO and not caring, helped underline the point . . . – Wyatt Barnett Sep 30 '11 at 15:40
  • 5
    The **bus factor** argument is so relevant the ability to resist that disaster scenario is even formalized by ISO as **ISO 9001** certification. (in small shops it pretty much sums up to that and that alone - bigger corps get it harder) – ZJR Sep 30 '11 at 15:44
  • 1
    I would rather the Lottery factor. It doesn't even have to be 300 million. What if you only win $50K? If you're in a really bad job, you may use the money to finance yourself over the next few months for finding a new job. Lottery can be any situation that causes someone to leave the company unexpectedly, be it the actual lottery, inheritance, a new job opportunity, or some other kind of "Lottery" http://www.classicshorts.com/stories/lotry.html. Lottery just kind of has more positive connotations associated with it than getting hit by a bus. – Kibbee Sep 30 '11 at 16:33
  • 1
    Yes but who cares about the positive to you? Either way it's a negative to the company, and you'd might as well use one that is a DEFINITE issue, rather than a PROBABLE issue. If you win the lottery you could still work at the job if you enjoy it enough. If you get hit by a bus you don't have a choice in the matter. – fluffy Sep 30 '11 at 17:56
  • @Kibbee I'm so with you on that. "What if you get hit by a bus?!". Isn't a nice way of looking at it. If anyone gets hit by a bus, any system reduces in significance to almost nothing. – Iain Holder Sep 30 '11 at 19:07
  • 2
    Unless it's a bus navigation system. – Iain Holder Sep 30 '11 at 19:07
  • Sure, we say bus factor but the most probable factor is the "found a new job, see ya!" factor. – dotjoe Sep 30 '11 at 20:09
  • 1
    If he doesn't get the bus factor, then put in for 2 weeks vacation (or whatever you got). Tell him you and some buddies are going on a (hunting/fishing) trip and won't be in range of cellphone or computer the whole time. Be excited, don't make it sound like you will cancel if he begs. They will die without you for 2 weeks and he will get the bus point. Then while you are (hunting/fishing) be hunting for that new job in a bigger shop with mentors. – Bill Leeper Sep 30 '11 at 20:48
12

You could try to sell bringing in a contractor to do this project. Sometimes it is easier to sell a short term solution then if it works out well and you can demonstrate the need it could transform into a full time position.

The best way to sell it is by selling the new solution as something that will save the company money. You will need to estimate how long it will take and do not try to be too agressive here. You might also find a list of the would be nice to do projects that you do not have time to accomplish now.

SoylentGray
  • 3,043
  • 1
  • 23
  • 31
  • 1
    +1 for contractors on work like this. The prospect of hiring a new employee is extremely unnerving and risky for very small companies. – maple_shaft Sep 30 '11 at 15:35
  • I agree. A few years ago I was brought in as a contractor to work on a project that the junior programmer already at the smallish company couldn't handle (a .NET web service). I ended up going perm and staying there about 3 years until the company was sold and our office was closed. – jfrankcarr Sep 30 '11 at 17:04
  • If nothing else, bringing in a contractor might encourage the company to see how cheap having developers on staff can be, compared to constantly hiring contractors to do the work of permie staff. *8') – Mark Booth Sep 30 '11 at 19:50
  • Or if you just want "more hands on deck," and don't care about experience, a cheap CS intern might be advisable to the costly contractor option. – recursion.ninja Aug 10 '13 at 21:38
  • @awashburn - The op does want a long term solution. An intern is often a crap shoot on quality, and often does not turn into a long term asset. Where a contractor comes in with a skillset and should be able to contribute quickly and effectively – SoylentGray Aug 11 '13 at 14:53
6

This is always going to be about cost. A new developer is going to cost them in salary, benefits, resources and probably training (at least training towards the business's model). Since you only list that you're working 50 or so hours/week and would like to see a more directed software production policy, a new hire is just flat out not going to be a reasonable prospect (business-wise).

You might have more success attempting to recruit from within. It's obvious that your boss/supervisor needs to be in on the process and should be aware that you feel you're being stretched thin and could use some support. It would not hurt to find someone within the company similar to yourself who is looking for a new challenge or a change towards this kind of task. Ask your supervisor to help lead an effort where this person's responsibilities can be stretched or altered to provide you with assistance. Gradually this can be increased over time until that person is completely working in tandem with you are (basically a transition similar to your own).

It's always a bad idea to throw too big a number (which a FTE amounts to from a business perspective). It sounds to me as if you do not work in an industry that produces software but that your company produces software to help support its business. So in any situation where you feel management needs to open the wallet even a little bit, you'll need to make it very attractive to the business. Big spends need to have immediate or large payoffs. Little spends are easier to get through the cracks and ultimately achieve the effect of a big spend through attrition.

Joel Etherton
  • 11,674
  • 6
  • 45
  • 55
  • 1
    This is a very good point. If you're working 50 hours a week (or even if you're working 60), then your boss is paying one salary for 1.25-1.5x the work of one person. If he hired a second, and the input didn't change, he's now getting the same output for twice the cost. Even if he gave you a 25% raise, he's still coming out ahead versus hiring two people (and paying two subsidized health care premiums on top of double the gross earnings). Where that puts you is between the proverbial rock and hard place; you can either accept an unreasonable work schedule or get out. – KeithS Sep 30 '11 at 19:22
  • 1
    @KeithS - That's not what the questioner is saying though. He's working 50+ hour weeks and yet still not having enough time to do new development, so he may not even be coping with half of the workload that's actually required to fulfil current and future business needs. – Mark Booth Sep 30 '11 at 19:40
  • Then in that case the input WILL change; it'll increase to take advantage of the throughput of two people. It still must be determined whether there is enough input to justify two people long-term; just having a backlog in itself is no problem, but if the size of the backlog is growing because more is being added to the end of the list than OP is taking off the top, there is a clear business need for more development bandwidth of some kind, whether temp, contract, part-time or full-time hire. – KeithS Sep 30 '11 at 20:05
3

I suggest you explain them what you are explaining here. Those are valid arguments you should bring to your boss anyway.

Maybe you can suggest hiring a trainee, if they raise economic concerns.

xsace
  • 695
  • 4
  • 15
  • 2
    Using the term `Intern` often seems to go over well with my bosses. They see it as `free or cheap labor`, and you can probably check with local collages to see if they have any students looking for an internship. – Rachel Sep 30 '11 at 15:35
  • 2
    Interns are indeed free or cheap labor, but they're also a revolving door (one intern won't work for free forever), and they're completely green (which is why they're working; for experience that's worth money later). Using interns to develop business-critical software without highly experienced senior developers on staff to mentor them is a VERY BAD IDEA. Even guys making six figures can totally screw up architecture; what do you think someone with only academic experience working for free and leaving in 6 months will do to your software? – KeithS Sep 30 '11 at 19:25
  • 2
    Interns typically have an overall negative productivity. You hire them for what they will be, not what they are. It is a great idea to invest in interns if you know you will need to grow in the next couple years, but they are not an immediate fix. – Morgan Herlocker Oct 04 '11 at 14:11
3

Be direct and don't worry about underselling yourself. Instead, hope that a more senior programmer will get hired. Its important that you are challenged by programmers that have more skill than you, especially in your first few years.

coder
  • 2,029
  • 2
  • 15
  • 15
3

Look into hiring a consultant...PM me, and I'll get the necessary paper work started :)

Seriously though, maybe someone could come in 20 hours a week and work on the code with you, you'd probably benefit also from having someone more "advanced" coding next to you.

You get all this with none of the risk of hiring someone.

jim
  • 280
  • 1
  • 7
2

When it comes to asking for raises/bonuses, you have to put your worth to the company in the context of how much money they make as a result of your work and what someone with your ability can make in the current job market. In your case, you're looking to establish the value of software development and whether or not the money is there to hire another developer.

Start finding out the value of this work to the company. Information is power. I undersold a custom application I wrote for a company. I thought they were some small company owned company and gave them a break only to discover they were being bought out and the application help to legitimize them in their industry.

JeffO
  • 36,816
  • 2
  • 57
  • 124
  • I disagree. The value they get from your work does not actually give you any leverage, since they can always get another developer to do the work. This is a common fallacy. – Morgan Herlocker Oct 04 '11 at 14:29
2

Do you havea a backlog of work you can't get to? Make sure to reference that in talking to the boss as well.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
1

Could you try to paint the picture of them wanting X amount done in Y time and that in order to make that happen, it would be best to bring in my hands to assist in getting through that work? A key point here is to be able to show that you are stretched and that it is probably quite risky to try to put all this on your shoulders while if there is another set of hands that can help quite a bit both for the organization, yourself and this individual. Make it a win/win/win for everyone.

JB King
  • 16,795
  • 1
  • 40
  • 76
1

Do a small but valid cost-benefit calculation of hiring another junior, mid-level, and senior programmer. Note that you must include that the more tiered you are, the more mistakes you will makes therefore the less productive you will be. But fundamentally, it all comes down to costs -- perceived and actual.

Note that cost is not only money but quality of code, early bug resolutions, and quality of life.

1

Get something to compare your situation too whether its talking to friends at other companies, going on interviews and asking questions about their dev team, etc and then lay it out there that you think the workload is unreasonable and that the company is not set up success with just one developer. I did this with a past boss, ended up quitting anyways for a better job, but basically I said things about how having a testing team becomes a necessity with the more code that is written, due to regressions, etc (not necessarily related to what you are asking but having testers on hand helps with the deve process too) and that you know you are working more than the average developer, etc. It sounds like you may want to look for a new job if he doesn't agree, he should already know that you are overloaded and if he's that clueless to not know then that it may become an untenable situation for you at some point.

programmx10
  • 2,097
  • 13
  • 27