Take the 2-minute tour ×
The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It's 100% free, no registration required.

I've been programming for around 3 years now, I love everything about building software and programming since the day I started till now. I work on side projects and write about topics I find interesting on my blog. I love what I do.

Recently I was sick of my corporate job, more like sick of the people leading the projects and noticed that I wasn't learning anything new. Then a start-up contacted me for a new job with a nice offer as an in house developer as they wanted to stop outsourcing projects and just develop them in house.

I saw an opportunity of freedom of tools, frameworks and learning new things to apply directly in new projects so I hopped in. Not to mention the new experience I can get through working in a start-up environment.

From day 1, I started designing and building a new project and everything was looking good.

Until:

  • Rapid changes of requirements started popping up
  • Everyone walks in and asks me about estimations for a new project they decided about the same day and how can I squeeze that in.
  • Complaints to fix bugs "ASAP" I didn't make from a legacy codebase they had that I need to maintain.
  • 1 week iterations with a handful of deliverables

Within 4 weeks I ended up realizing that I have to handle 3 projects at the same time while maintaining top productivity in all and satisfying all parties involved.

Being relatively inexperienced in leading projects I thought that I might not be putting enough effort so I started working on weekends to cover up any time wasted during the week on one of the projects. The stakeholders were impressed by the efforts but I didn't mention the extra time I was putting.

This week I was feeling tired so I didn't put enough effort on one of the projects. I will be missing this week's deliverable yet the stakeholders have high hopes to see something awesome tomorrow.

I just don't know what to do. I keep blaming myself as lazy but I do feel tired. I love building, I love programming but I just can't seem to succeed without a technical person managing me probably.

share|improve this question

closed as unclear what you're asking by jmac, CMW, RWY, jmort253 Mar 18 at 13:40

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
Is what I described above normal to have? How can I manage the situation so that everyone stays happy? –  Ayman Farhat Mar 16 at 14:06
1  
In an unmanaged environment, sure. Lots of people want to have their stuff done as priority #1 and so you have to figure out how to ensure expectations are reasonable. I'd suggest talking to your manager about how much they expect from you and whether or not another developer could be useful if you are really overloaded. –  JB King Mar 16 at 16:21
27  
Really you have to learn to say no, assertively. This means telling people that all tasks cannot be completed when they want them in a respectful manner. If you always say yes, then you end up doing everything poorly, with the result that everyone is angry at you. You need to say things like "I'm working on Bob's task right now, it is going to take me 2 weeks, if you guys think that I should switch to another task, you and Bob need to decide which task is more important for the business..." –  daaxix Mar 17 at 5:43
2  
I recommend the book "boundaries" by Townsend. –  Peir Mar 17 at 16:00
2  
Please don't forget to write a comment or update your question telling us if and how things resolved. It's important, otherwise it will be only half the story... –  Radu Murzea Mar 18 at 9:51

8 Answers 8

up vote 40 down vote accepted

Everything you mentioned sounds pretty common in software development and/or working at a start-up (from what I hear), not to mention combining the two, and being the sole developer with (seemingly) no single person to report to.

A few possible solutions:

  • Try to manage your time better. Not sure if this applies to you, but a developer constantly switching between tasks, or being interrupted, often lacks optimal productivity, as you really need to spend a bit of time on something to pick up speed. Which brings me to...

  • Try to manage the people better. I'm definitely not the expert on this one, but you could perhaps try to arrange to receive everything but the most urgent of tasks via email, or via formal meetings (scheduled by email, possibly scheduled to happen at some preferred times during the day) causing much less interruptions. This assumes that you don't deal with e-mails as they come in (as this has the same problem), but rather at some predefined points during the day.

    I imagine you may also need to, some way or another, point out that you won't be able to deal with tasks assigned by certain people right away, as you have more urgent tasks to deal with, occasionally reschedule tasks if something more urgent comes up, and prioritize tasks assigned by different people, as it's rather probable that they won't discuss the priority of their tasks amongst themselves, leaving you to do that, or work yourself to death in trying to keep everyone happy.

    The above might be difficult to do, especially considering that most / all of the people assigning these tasks to you are likely your seniors, so you may need some help...

  • Go talk to your boss. Most people would be understanding and try to come to some sort of arrangement that would work for everyone. They will perhaps:

    • Get you another developer. Same amount of work, double the workers - good plan.

    • Help with some / most / all of the "Try to manage the people better" part by having an informal chat with the applicable parties, or putting some formal framework in place for scheduling your time (and perhaps the time of other employees in a similar scenario). This could involve trying to...

    • Get you a project manager. This will most likely be someone with other responsibilities as well (possibly already working there), as getting someone just to manage your time isn't particularly likely, unless you're management. This would ideally be someone who knows enough about software development, as a very, very common complaint is that others just don't 'get' it - they expect unreasonable things, they don't understand why things are taking so long, etc. Having someone who knows the business lingo to explain these things in understandable terms to everyone else, while eliminating most of your distractions (as people should speak to the project manager, instead of to you directly, to schedule your time) should help a lot.

  • Just hang on. Start-ups aren't start-ups forever. You can definitely expect long hours at many start-ups, but, if the company succeeds, you should be reaping the rewards in a big way. Now I'm not saying you should work yourself to death either - working too long hours for extended periods of time is detrimental to productivity - you'll have to figure out whether you can find an acceptable balance between working a maintainable amount of hours and doing the required amount of work.

  • Leave. As mentioned above, the problems you're having are pretty common, and not necessarily something you'll be able to change in any given role, so, if all else fails, you may have no other option than to hand in your resignation.

share|improve this answer

Talk

If you're a solo developer in a startup, then 'stakeholder management' is an entirely different situation than it's often in large companies. There shouldn't be that many of them - get them in the same room and talk.

That talk is a big thing for the company at this stage! The startup needs lots of technical stuff to be done; and you are (at the moment) the main engine of a tech startup. The ordering and priorities of tech projects are a key, top-level decision that greatly affects the whole company. "Doing all projects at once equally" may be a very stupid strategy if you can't actually do all the projects.

Estimate knowing your circumstances

You know that you have X parallel projects and you've already seen how large immediate maintenance/bugfix tasks tend to pop up. If you make estimates, take that into account - a four-hour task won't be done tonight, because you have to finish the current task that will take until lunch, fix a few bugs which will take 0-3 hours and do that other task for that other project you promised yesterday; so you won't even start that four-hour task tonight.

Get used to it

In the foreseeable future, the environment will be exactly like that. The only thing that might change is your own understanding, and the understanding of your teammates.

There will be those rapid changes to requirements and throwing away of semi-finished work; there will be a need to rapidly estimate (estimate? prototype!) ideas that didn't exist an hour ago; the need to do impossible things ASAP; and short iterations with many deliverables. That won't change. However, inability to do everything doesn't make you a bad worker for this position (not unless it psychologically breaks you).

Effect change

As the sole developer at a startup, you should be able to influence the way technical projects are done there. If you're not, well, unless the status quo is great (and it seems it isn't), then you should get out before you sacrifice your health and sanity for no good reason; but you should be able to change things.

You can change the expectations - understand your time, don't overpromise, don't burn out, and keep others informed even of unpleasant truths. If you promised that X will be done tomorrow, but more important things will take your today, tomorrow and the next day as well - it's okay; in a startup everybody would(should?) know those others things and understand them; but you have to keep them informed that actually X won't be done so they can replan accordingly. It's expected - just as you have to change plans as requirements change constantly, they probably are used to do the same.

You can change the way you work - 'move fast and break things' is very different workstyle from 'triple-check every deliverable for typos'; in a startup it may be beneficial (and required) to sacrifice quality in order to gain time. Often, a very minimal prototype held together by string and bubblegum can be sufficient. Technical debt can be a real burden, but it's sometimes the proper strategy to knowingly take on tehnical debt - there are many successful startups that needed to throw away and replace the horrible code+systems they had initially; but they wouldn't be successful if they had taken the time to build them properly the first time.

You can change the focus - at a startup, there will be many things that seem to urgently needed and priority #1. About half of those things won't get done anyway, and you'll survive another year without them - but if you pick wrongly, then the startup will fail. It's probably more a decision for whoever hired you - but it's quite likely that half of the projects need to be postponed so that the other half get done faster and better.

share|improve this answer

I think the biggest issue you have is the fact that you are working on these projects and there is no clear structure or direction. The worst thing in the world is once you start building something that you thought about a lot and people come and start demanding more from you.

You could try to modularize everything you do and build for reusability and document it thoroughly. When managers or customers come to you and ask for a lot of features you need to be able to say no. I know that you feel like you need to please everybody but you should not be 100% flexible when implementing new features that were not thoroughly thought through.On the long run this will affect the products you are working on.

You need to take control and demand clear deliverables and only allow small changes each sprint so it will not affect your goals that you set for that week. Also, working in the week-ends? I understand dedication, and i used to to this as well, but the week-end is there to either take a break or work on the things that you love and that will help you on the long run, not just some stupid project that you will not be able to showcase or use to learn a lot of new things.

So, in the end, plan better, don't take every suggestion in and explain how this affects the quality of your project. I bet many of those things are not actually necessary. Plan them for another sprint later on. Take your managers or your customer and have a long discussion explaining the process you have in place, and how this disturbances affect the quality of your work. If the manager is non-technical, sit down with him and explain all of these things. He might then understand how the project works, learn something new and maybe together you can come up with a better way of doing things.

Hope this helps. :)

share|improve this answer

Is what I described above normal to have?

Yes. Very. One of the big challenges of software engineering (and engineering generally) is determining reasonable time estimates for work requests. Working closely with stakeholders to agree on reasonable expectations.

How can I manage the situation so that everyone stays happy?

You cannot please all of the people all of the time. There will always be more demands, and that is a good thing. Just do the best you can, be as productive as possible while mitigating technical debt and relax about the outcome. High intention, low attachment. Also, get the balance right between obligation to your employer and obligation to your own health and well being.

share|improve this answer

Here is what, in my opinion, you'll want to do:

Document everything.

If you're not familiar with putting together design documents, consider this a great time to add that skill to your resume. I've worked at jobs like this and what you absolutely need to do, before you do anything else, is put together a design document which explains in exhaustive detail as many use case scenarios as you can think of, talks about all the end-user bells and whistles that your client wants you to add, and even (if you can manage it) provides a general timeframe of when you will be providing which deliverables.

It's my experience that this is by far the most important part of this process. I realize that non-techie types will not always enjoy getting together with you to decide in advance what buttons should be on a page or whatever ("that's YOUR job!") but if nothing else, the fact that you've put this document together means that later on, when your client tells you that they want to add features X, Y, and Z, you can say to them "okay, sure, I can do that, but it will cause this product to take [amount of time] longer to develop.

Oh yeah, and when these features are added? Put them in the design document and get the client to sign off on the changes.

I realize that as a developer this feels like a lot of extra time doing something which is not actually programming and therefore does not feel either productive or fun, but look at it this way: your design document will serve as something similar to the outline of the book you're going to write. Nobody's going to "read" the book in the classic sense of the term but they are going to use it and it's important to know exactly what that book's going to be about before you start to write it.

Provide deliverables as soon as you can.

What I mean here is not that you should stay on schedule, because of course you want to do that (and from the sounds of it, that may not be any easy thing to do anyway). What I mean is, try and get something out to your client that they can look over and approve/request changes to as quickly as you can. If you're designing a web page or a WPF application, for example, get them a wireframe as soon as you possibly can. As you wire it up and add features, present these to your client as soon as you get them done so that they can test them out (caveat: some folks just won't test stuff out until it goes live or is about to, so don't rely on this; however, you can use this as an opportunity to say "I presented Feature X to you 3 weeks ago. I can change the way it operates for sure but this will take X amount of extra time."

Treat development, testing, and design as interrelated parts of the larger process, not stages you get to clear.

It kind of amazes me when devs do this, and I'm not saying you will, but it needs to be said: the time for refactoring code is whenever you get a chance, the time for a redesign is whenever the client requests something that you can't provide in the current design, and the time for testing is whenever you're programming. I realize that this method can create spaghetti code, but that's why you refactor.

Additionally, if you're the lone developer at your company, your co-workers/clients are not going to know what the "development process" is. They'll have requirements that they want you to meet. Sometimes they'll realize halfway through a job that a requirement they gave you needs to be more robust, or that a way you solved an issue creates non-functional problems they didn't express at first.

Never say "I can't.

Well, I guess if they want you to design a new version of Call of Duty all by yourself in 2 weeks, you can say that you can't do that in that amount of time. But what I mean is: if your clients/co-workers give you a feature, don't tell them that it can't be done. If it's going to be hard to implement into your existing design, advise them that you'll need to refactor a bit and that it will take longer (try to provide an exact time - if you over- or under-shoot, you can always adjust that later). If you literally don't know how to do something, advise that you'll need to research the solution and that you'll give them an estimate of the added time within a day or two. If there's a physical limitation preventing you from doing what they want, or if what they want would violate some other principle ("hey, can you make it so that people can see their passwords?") then provide other solutions in lieu of "I can't".

Constantly communicate.

If you can manage it, a brief 10-15 minute daily "scrum" style meeting wherein you briefly discuss what you're working on and maybe get some minor bits of clarification is good even with non-devs. I know that sometimes you can get into that "meeting hell" wherein you're spending more time talking with people about what they want then actually providing it for them, but generally I think programmers tend to err on the side of putting their heads down and just getting stuff done, so it's not a bad idea to maybe push yourself towards constant verification with your stakeholders.

If nothing else, a weekly or twice-a-week meeting where you present what you've done so far and discuss the challenges that lay ahead ought to accomplish a few things:

  1. It'll help you cultivate your own communications skills (not to say you're not already a good communicator, but this is something all devs can and should work on).

  2. It will give your client/co-workers confidence that a. you know what you're doing and b. you understand their needs.

  3. If you do get behind on something, or if there's a major change which is suddenly necessary, you and your client/co-workers won't feel blindsided by this.

Anyway, that's what I've got. Look at this as a challenge and an opportunity, not as something which shall necessarily cause you to pull your hair out. Working with non-techy people can be a curse (sometimes they ask you to do things which are all but impossible and don't understand why you can't just get it done) but also a blessing (sometimes the smallest little addition that took you all of 5 minutes to code can make you feel and look like a total hero).

share|improve this answer
4  
'Document everything' might be counterproductive at early stage startups - since all of the details are expected to change, the only purpose of the initial design doc is to communicate with the "product decision maker" - PM or CEO or internal end-user or whoever. For this purpose, it might be just as fast to produce a semi-functional prototype - if a napkin-sketch isn't sufficient, then it's just as fast to code up a webpage with the feature (maybe 'mocked' depending on its nature) than to write a document showing the same thing, and the page allows better 'what should be different' talk. –  Peteris Mar 16 at 22:20

There are some great answers here about managing the requirements, but I'd also like to highlight that you're going to have to manage yourself as well as your stakeholders.

As an example, working on the weekends is not a solution for even the relatively short/medium term. Dan Cook has an excellent summary of the research around productivity in Rules of Productivity Presentation. The TL;DR is summarised on a graph on that page, and says that 40 hours a week is the optimum for long term productivity: it only takes a month of 60 hour weeks before fatigue costs you the extra productivity (and you're working 60 hour weeks to achieve 40 hours worth of work), and in the next 4 weeks you lose as much productivity as you gained in the first 4.

There can be a very macho culture around start-ups, but that doesn't make it correct.

share|improve this answer

Execution, successful startup is N% idea and (100-N)% execution, i.e. your assumption about learning new things was generally wrong.

New Stuff, you are, presumably, working on something new, thus an assumption about existing frameworks, etc, is quite flawed too.

Business, start-up is typically defined as an attempt to find repeatable and scalable business model. That is it's not about your code, or even who codes it, it's not even strictly about what it does, it's all about how it's received, how it fits into (ideally disrupts) existing ecosystem.

Adapt! Finally, to be a successful startupist, you have to adapt, you have to anticipate required dev effort and switch from role of developer to, say, HR to find a few good programmers, or manager to look after junior devs and interns, or outsourcing specialist if some of the code is done off-premises, or sysadmin when required or a spokesperson to promote your startup at a conference.

Hopefully you hold a share in this company consistent with being one of the founder or 1st hire or sole dev or cto (your post didn't specify). Please check if that's the case, and if not, get your founders to adjust your fiscal position. If they fail, quit asap.

Finally startups are different things to different individuals, see that movie about history of Apple, for some it's money (after bastards), for others it's engineering novelty and excellence (often screwed), yet for others it's a great experience and for others still it's a way of life. Startups are not for everyone, but anyone is free to try. That's the beauty 😼

share|improve this answer

Man, this post brings back memories of jobs past. Getting all sentimental.

If I have one piece of advice it's this: PRIORITIZE. The majority of the stuff people want from you simply is not going to get done; there are only so many hours in the day and only one of you. Prioritize and work on the most important things first - the projects that are going to get the best ratio of return to time invested.

share|improve this answer
1  
this seems to merely repeat point that was made and explained in two top voted answers posted long before –  gnat Mar 17 at 18:46
2  
@siliconrockstar This is why your answer may not be as appreciated as you would like it to be. –  CMW Mar 17 at 20:10
1  
Hey siliconrockstar, prioritization is most likely the key to solving this user's problem. In fact, you may be able to elaborate more with that as your focus. For instance, you could relate this to a personal experience that happened to you, address an area where you can see the op should have prioritized one thing over another, or you could provide references/case studies that help elaborate. Hope this helps. –  jmort253 Mar 18 at 5:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.