Worked alone for the same company during 7 years, now I feel like I lack a lot of basics skills

Question

Backstory

I started as an intern in this company during my 3rd year of university. I then continued with a work-study period of 2 years before joining the company at the end of my studies. It has been 5 years now. I worked alone for 4 years, then we hired another developer at the end of his studies. Last year, we hired a 3rd developer, at the end of his studies. There are 15 employees in the company, with 3 developers.

My job title is "Full Stack Developer" and I am doing the job of a tech lead. I defined a DevOps workflow with Jenkins to deploy what we implement in our private nuget packages repo and our private docker repo, sends. I design the software that we work on, plan the implementation, manage the team and works on the packaging and deployment. Clients contact us using Jira or a specific email address that creates issues in Jira.

However, if I am being honest with myself, I am really bad at managing and planning. I rarely achieved my goals in time. I can't properly estimate deadlines and I rarely meet my deadlines.

When I broached the issue with my boss, he hired contractors to support me, with whom I work a few hours a week. To numb my conscience, he gave me a generous increase (+ 25%), to prevent me from deserting the company. It felt nice for a year but I feel like I haven't progressed. On the contrary, I get impression that I am falling behind. I'm almost 28 years old, but I still feel like a Junior.

How I found out

I wasn't always honest with myself but I kind of felt this. When a company reached to me I accepted their offer to work with them part time just to see how things would go. At the end of the trial period, they told me 2 things: they greatly appreciated my work and the quality of what I produce, but the missed deadlines are a red flag and enough of a reason to stop. Which is normal I guess. The problem is that I have the feeling that until I work for a project manager or someone who will manage in my place, I will never be able to improve on this point.

The hesitation

I have a good salary, but I honestly think that I am under-qualified for it. However, I don't know if I should accept to lose almost 30% of my income to correct the trajectory of my career or if I should "fake it until I make it". Also, I am married and a father, so reducing my income will impact the quality of life of my daughter.

I feel lost and I am scared. What do you think? What would you do in my place?

Answer 1

Is there a culture on the "business" side of the company demanding or expecting estimates to be small?

I know I've worked at a place where there was a lot of pressure for smaller estimated times, and it only caused a larger gap between estimated completion times and actual completion times.

Plan

What I do now (as an independent contractor) is take a feature, break it down into very small steps (about half hour to several hour chunks). Breaking tasks down into as many small tasks as possible will generate much more accurate estimates and will give you more tasks to explain why a feature will take long to your boss.

Make sure to include research and planning/re-planning time (people often forget those). The more uncertainty there is or the more research needs to be done, the larger the estimate must be padded. Also make sure to add items for unit testing, cross browser testing, documentation, deployment, demos, code review, a task for changes that may need to be done after completion (look at how long change requests usually take and apply it to this feature), management, meetings/communication, etc.

I use a personal wiki / outliner software called zim-wiki (similar to Evernote/Onenote/Notion/Obsidian/etc) and create an outline of tasks and subtasks multiple levels deep. I start the outline by copying/pasting a checklist template with common tasks like the above that I often forget to include. This is in addition to project management software like JIRA and is your personal plan for a JIRA task (you can add the outline or a summary of it to JIRA if you want).

Sort

Next, sort the tasks from highest risk/unknowns/difficulty to smallest. There have been so many times when I've went through a feature completing items in the "logical" order, sometimes doing easy/medium tasks first, and when I got to the hard parts, I realized that I had to completely redo the previous steps. This was because while working on the hard/unknown parts, I realized my approach was incorrect. Doing the hard/unknown parts first (to the extent this is possible for a given feature) is crucial. The easy parts will practically take care of themselves as you slide into finishing the feature.

Estimate

Estimate every task at the lowest levels of your outline. Remember that you have a bias to be overly optimistic and estimate best case scenarios. Remember that your boss most likely treats your estimates as a deadline (i.e. close to worst case scenario). Use estimates that are about halfway between the average case and the worst case (adjust this as needed). Over enough tasks, this will even out to give you enough padding to complete features on time almost all the time. Round up each task to the half hour or hour. The only exception is that if I'm confident that a few tasks will take less than about 5 minutes, I might group them into one half hour chunk.

Then, sum up the hours at each higher level of the outline and after every summation, gut check the estimate - does this sound like a realistic estimate to do this ENTIRE task? If it doesn't, add some padding to the subtasks until it seems like you will have more than enough time to complete them. Add extra subtasks too if you come up with them. Tasks often take up more time than you expect and giving yourself a very comfortable amount of time to do them is important.

Common padding amounts range from doubling to quadrupling the time if you haven't done this task in this environment before. Consider padding even more if there's research or many unknowns involved. Whether to use specific multiplier(s) or not is a personal choice that you should experiment with for yourself and decide whether it works or not. I just use my gut feeling about whether I'm comfortable with the estimate. But the gut check must be from your gut, not your boss's gut.

If you think your boss will complain about how long it will take, look at your task breakdown and write down a few notes explaining why it will take this long - the cross browser testing for this feature will be tricky, the algorithm may need to be optimized, there are multiple possible solutions that must be researched and tested, etc. Have these ready when you tell your boss the estimate.

Track

Then track your time as you work and adjust future estimates as needed repeating this process (add a half hour to an hour for re-planning/re-estimating when you do this). For time tracking, you can use a spreadsheet or software like Toggl, but also add actual times to your planning outline e.g. here's a sample task that took 3 hours even though it was estimated at 2 hours (I use a slash between them):

[*] (3/2) research library A for feature X

Communicate

If it's taking longer than expected, communicate this to your boss as soon as you can. Do another estimate-gut-check and give your boss the updated realistic estimate. Don't give them a smaller estimate hoping you can catch up - in fact, consider adding additional padding so that you deliver on or before your new estimate. If your previous estimate was too low, it's almost certain that this one will be as well, so account for that with padding. Track this time re-estimating and communicating with your boss.

Review

As you work, review your estimates and planning outline regularly. Repeat this process for every feature you work on until you get better.

I've noticed that using the estimate gut check and padding tasks until you feel very comfortable that you can complete them in that time has really helped me. And taking notes on why a task will take long and reviewing those before you speak to your boss has also helped.

At the end of the day, remember that accurate estimates will make your boss's life easier and if you can deliver on that, they should be happy.

I would stay with your current job and work on getting better at estimates. You're clearly valuable to the company and deserve the salary you're getting paid. Just keep improving your skills.

P.S. Here's an approach to padding estimates by multiplying them by a historical velocity ratio: https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/

Other things you might consider doing:

• Ship smaller features for more accurate estimates (what is the smallest independent unit of a feature you can ship?).
• Shift to a shorter sprint cycle like a 1 or 2 week cycle (if you do this, make sure sprint overhead is low enough to accommodate this).
• At the beginning of a project and also if it's running late, cut scope, not time estimates whenever possible. It's almost always better to ship fewer higher priority features on time than to ship more lower priority features late. Scope can be much more flexible than it seems.

Answer 2

When I broached the issue with my boss, he hired contractors to support me, with whom I work a few hours a week.

Your boss is only solving for one aspect of the problem here: the amount of work that can be done in a time period (to reach the deadline) rather than helping you improve on how to better estimate in the future.

You say that you're bad at planning, but to be honest most software developers are to some degree. "Project management" has developed as its own job field to specifically account for this type of work outside the "hands-on" development work.

Some suggestions I would have are:

• Ask your boss to hire a project manager specifically — someone who will manage the delivery and can help the team refine estimates, highlight where there is risk to meeting target dates and add contingency and fallbacks
  • You might need to make the case for this role if your boss isn't aware of the need or the benefit it could bring (e.g. less customer frustration, if target dates are more reliable). Since he's been open to bringing in temporary contractors, you could suggest a contract role here — e.g. someone to join for 6-12 months to see if it provides an improvement.
• Ask for training around software estimation (or at least a good book) so that you can give estimates that you're more comfortable with in the future. Sometimes people underestimate how long something can take if things go wrong (e.g. focusing more on the best case scenario) or fail to factor in work outside of development (meeting/communication overhead etc).

It is good to get better at estimation and planning, especially as you move into leadership, but it doesn't all have to be on your shoulders.

Answer 3

I feel what you describe is normal and seems to lean toward the imposter syndrome where there are similar asked questions on this site. You seem to evaluate your skills by focusing on estimate, may be the hardest thing in IT.

Personally, I no longer believe in "hard" estimates in the development fields: there are a lot of dependencies with other resources, scope creep, unknown technical challenges, specification and priorities changes, etc.

Additionally, estimates from popular development methodologies are very rough: 1 to 4 weeks.

I was in a similar situation in the past, I did change job for the salary increase but this emotion came back. I got this feeling fade away by participating at various hackathon, meetups, etc. Learn a lot and learned that I also knew a lot: IT is a large field.

Here some propositions:

1. Get exposure like @Kaz answer suggested: volunteers to an open source project, participate to hackathons and meetups, to exchanges with other peoples in the same fields at popular events.

2. Subscribe to live training, books, online platforms, forums, management certification, etc. to know more about estimates, the good and the bad.

3. For a short period, write a diary of your days: tasks description with duration and information (business and technical) you had at the moment. Then at the end of a delivery, try to identify the delta between your estimate and the delivery. Repeat for a few deliveries.

Theoretically, you should get a picture of why the estimates were off and be able to improve them when the issue is on your end. Depending of your organization, it may not be possible to improve them by far:

• there are some unrealistic deadline because of somebody promise something to somebody else;

• there are some managers prefer to get an answer "next week" four times instead of the true estimate: 4 weeks.

A job you love is very important and hard to find. I take you love your current job because you are there for 5 years and your employer seems to appreciate you by the salary increase.

I really suggests to try this before changing job because the vibe I get from your questions is you are under evaluating yourself and you may quit a job that fit you personally while your financial situation may impact your family.

Answer 4

No one is good at estimating software. Some people who seem good at estimating are actually good at managing scope and expectations. When it starts to look like a deadline will be missed, they start negotiating to pull things out that weren't really that important. People who are really good at it, start that negotiation when they're first given the task, and try to partially deliver in small chunks as early as possible, instead of all at once.

Even when you work somewhere with good mentors or colleagues that help you improve, eventually you hit a point where you are the go to guy, not only for yourself, but for helping others on your team improve. Your resources mostly become external at that point, like books and conferences.

Thanks to the pandemic, more conferences are online now, both live and for viewing the recording after the fact. Search YouTube for software estimation and you'll get a ton of ideas. Use it to set a goal, try something out for a while, then evaluate and adapt. When you get a chance to attend a conference in person (which your employer might pay for), the best part is often the conversations in the halls. Tell people your concerns, and you'll find a lot of people with the same concerns, and some ideas they've tried to varying degrees of success.

Answer 5

Do you keep explicit track of the time it actually takes to complete tasks (for yourself and other team members)? If not, that's one small step that should help.

I had similar issues when I was trying to stop doing my homework in college at the last minute. Occasionally, I underestimated the time it took and turned things in late. So I started actually keeping of log of how long it took me to get tasks done. I would categorize it into things like, "reading a chapter" or "writing a lab report". Eventually, I started to see a pattern and could plan ahead.

I eventually applied this to my current job, which is as lead engineer of a tech product. I handle the project management of all technical work (largely software engineering) while the actual product manager handles the marketing and customer relations side of things.

I track the time to finish every key task in the project. At first, I went off of whatever I could find of the previous engineer in my place (which was very minimal to say the least). I made a goal for the time to complete a certain project, and it took longer than I thought, so I adjusted the next one based on that data. Each project might be different, but it's likely that certain types of tasks will repeat, so find your own way to break it up.

It took a few tries for me to get this repeating project to a reasonable time frame that doesn't go overdue. So don't be ashamed, no one is perfect when they start. And there are certain other organization priorities that can blunt even the best plans.

Ask your manager for access to a program like Monday.com or Smartsheets. That can help you visualize and distribute tasks to other team members (if Jira doesn't already have a feature like that, I don't use Jira).

Finally, if you really are doing a lot of project management, see if you can take an introductory class on Project Management. It seems simple, but there's a lot to project management and it takes practice and experience (which is why something like the PMP requires years of experience, not just an exam).

Good luck!

Answer 6

You really do learn a lot by working with other people. I have worked both on solo teams as well as with larger groups, and there is definitely an advantage to having people to learn from.

I had the same sort of concerns as you do. Someone once explained it to me like this. When you work on a team, your teammates all have different skillsets. Where one person is weak, another is stronger. You can think of the team's combined skill at something as sort of like the average of each team member's individual skill. When you work solo, you don't have that load-sharing ability so any weaknesses appear much more severe than they would on a larger team. You could actually be much better at planning than the average developer but it can seem that you're not, simply because your talents are directly visible and not aggregated with a bunch of teammates.

Don't let this discourage you. How things appear does not always reflect reality. There's also another side to the coin. Working solo also allows your talents to become more visible. People tend to focus on their own faults so they don't always pay attention to what they're good at doing, but other people see it. Take an inventory of the things that you're really good at doing, and use those as much as possible to compensate for your weaknesses.

On the other hand, being on a large team makes it easy to overcome your weak points by leveraging others instead of by improving yourself. Managers don't like to spend extra time giving you a chance to learn how to do something better when they can just assign it to someone else who can finish it quicker and easier. Working by yourself can give you more opportunities to practice skills that you might need some work on. It sounds like your manager is really going out of their way to support you. That's fantastic! Take advantage of that by talking with your manager about where you think your weak spots are and ask where they think your weak spots are (spoiler alert: it's common for these lists to be completely different). You manager is usually in a better position to evaluate your skills based on their impact to broader business goals, and they may have some insight into what sort of improvements would have the largest impact.

When it comes to estimating and planning in particular, here's something helpful that I've learned over time. When you ask me for an estimate for how long it will take to complete something and I tell you 4 days, that means 4 days of uninterrupted work on just that one task. When you're working solo, you almost never get that luxury. You're having to handle support requests, meetings, and all other manner of unrelated tasks. These are unpredictable and are not part of your estimate. If you're not done in 4 day's worth of calendar time, that doesn't mean you missed your estimate. It means you've been doing unrelated things that will unavoidably force your timelines to slip. Make sure your management understands the difference between an estimate in work time and an estimate in calendar time and be clear as to which type of estimate you're giving (this was the cause of many of my own scheduling struggles). It can help to keep an informal log of how much time you spend each day working on different things. When management complains about how long something is taking, you can show them that you've only been able to spend 20% of your calendar time working on that task so it will take roughly 5x as long as anticipated. This can also be a good tool for encouraging managers to keep some of that unrelated work off of your plate.

Also, missing an estimated deadline isn't a bad thing. It's actually expected. Don't forget what an estimate actually means. An estimate of 4 days doesn't mean that you'll have that task finished in 4 days. It means that if you did that task 1,000 times, the average length of time required to finish would be 4 days. A graph of completion time would look like a bell curve with "4 days" at the center. This means that 50% of the time, you'll take longer than your estimate. That's not a failure on your part, that's simply how estimates and statistics work. Many managers forget this and like to treat estimates as deadlines (especially managers that don't come from a technical background).

There are some things you can do numerically that can help as well. Keep track of your estimates vs. the actual time taken to complete the associated tasks. If you're going over your estimates more than 50% of the time, start padding your estimates more. Your goal is to get that "under-the-estimate completion rate" as close to 50% as possible. Also, keep track of how far off your estimates are from your actual completion times. I saw that my completion times were fairly consistently about 50% above my estimates, so I started padding my estimates by 50% to adjust for the inaccuracy of my "gut feelings". If your data has a lot of outliers (where actual-estimate is more than a standard deviation away from the mean), than that's a hint that there's something with high variability that you're not taking into account when you make your estimate. Sometimes it helps to break down the task into as many small sub-tasks as possible. These can be easier to estimate, and can help identify what parts of the project are taking longer than anticipated.

Answer 7

My personal story has a lot of similarities with yours.

What you need is exposure to better and more experienced/senior developers and managers. And exposure to industry best practices.

---

You can get it in multiple different ways:

You can try to persuade your boss to hire an actual Project Manager/Senior Developer.

You can participate in relevant stacks:

CodeReview

Project Management

CR also has a very active set of chatrooms full of helpful developers.

You can study and go on training courses

You can read and subscribe to blogs and mailing lists

You can join and contribute to Open Source projects

You can adopt a mindset of deliberate practice. Where you identify goals and metrics you want to improve, design and create ways to measure your performance, and then deliberately practice/experiment, record your results, and use that to improve yourself.

---

You can and should do all of the above. Failing that, you can always start over at a bigger/more established company, maybe at a lower level/salary than you are now, where they are actually set up to train and develop you.

You might take an early salary hit but if you're good at what you do, given your business experience, you should be able to rise back to your previous level within a couple of years, with the skills and experience to take it even further.

Answer 8

Software development is a field that is changing constantly, more than most. I see 2 paths to follow down that line:

1. Constantly stay up-to-date with the newest tech (I don't think "fads" is too inaccurate in most cases, but let's give the benefit of the doubt). Problems: you may often feel like the "perpetual junior" (I remember a blog post about the problem from a few years back, can't find now) because you'll meet younger people that know more about something than you. You may also have a hard time guessing the next best thing to brush up on, sometimes spending time on something that does not pan out. But: slowly but surely you will gain more experience: you will know the business better (domain knowledge), you will get experience with pitfalls (higher-level than just programming language, e.g. architectural, performance, etc.) And you will maintain your employability as more and more employers shift to newer tech.
2. Get deeper into what you are using now. This depends on your current employer staying with the same tech and be adverse to change. Are you happy to stay with (say) Java version 7 until you retire? Problems: this presumes your employer is in a stable economy and can virtually guarantee your employment for the next 30 or so years. But I think this is not a very safe bet, since you will probably get in new staff, hardware and software that will in a few years simply not work with current tech any more. And by that time you are stuck. So my feeling is that the previous fork to take is the safer bet.

The next issue is that you have been a generalist. "Full Stack" already implies comfort with multiple technologies. Now to that add things like project management, team leading, maybe business analysis. You should consider specializing a little bit more (choose area/s that are your forte). Now is a good time. Plan with your management and team how the other areas will be addressed: maybe hire another colleague, upskill one of the more junior people and assign more responsibilities, etc. I've seen options like the following among fellow developers:

1. Stay in development. There's no shame in it, and I chose it myself because I like building things. But then do focus and become the best developer you can be.
2. Some move into project management/SCRUM master etc. And we developers value someone like that that knows what developing software is about, who does not think of it as some kind of magic.
3. Or a Business Analyst/Product Owner or similar roles. Requires more focus on the domain and less on the tech.
4. Architecture/Systems analysis etc.?
5. Leadership/management if you are keen on the people side. Again, someone who knows development is often appreciated by the underlings.
6. etc.

It is always difficult to find out what you really want to do. Money-earning potential, not letting down the team, status, etc. tends to bend our focus. I found some online selftests useful for my own purposes: e.g. a Myers-Briggs based and/or the Gallup StrenghtsFinder - use at own discretion and/or find others. But try to get a good picture of what you want to do, then set up goals for yourself for the short and longer term - and work towards those goals, even of it means a new position or a new employer, and it will probably mean more work/learning, even outside of work. And steer away from things you are not good at.

And you are not limited to your current career. You could also choose to become things like

1. Entrepreneur: develop your own product and company
2. Contractor: provide valuable services to many companies (often self-employed/independent)
3. Save money and retire early
4. Change career to a completely different field (even part time, e.g. write a novel)
5. etc.

So there are many options. But be aware that things will change constantly and you need to plan ahead. If your employer is helpful in that regard, as yours may well be, do pull their input in. But in the end you are responsible for your way forward.

---

To discuss 2 more points:

Impostor syndrome has been mentioned by others. It's quite common and much has been written on it on the web. Realize that you may in fact do valuable work even if you feel like an impostor. But, as said above, realize that you can't rest on your current laurels, they will wilt sooner or later.

Time management has also been mentioned by many. For some personalities time is just of less importance than for instance doing good work. I think a lot of such personalities actually prefer IT work (e.g. Adult ADHD or autism spectrum, or just plain perfectionists). Find coping strategies if you can't avoid (e.g. adding your 30% to the estimate). One premise I liked about the Gallup StrengthsFinder linked above is that they exhort people to rather develop/enhance their strengths than try to work on their weaknesses - but that works better if your workplace allows people to use their strengths and let their weaknesses be caught by others whose strength is that area. So, make a gradual move towards such arrangements a part of your personal development.

Answer 9

I agree with others that you need someone to help you, but I disagree that it should be a project manager.

Traditionally a project manager does things like come up with estimates about how long a project will take, distribute tasks across the team, create status reports, "command and control". Firstly, this doesn't work very well (the person making the estimates isn't the person actually doing the work, which leads to bad estimates). Second, even if the PM makes good estimates for you, you still haven't learned how to make good estimates yourself.

Instead you need someone to improve your processes, preferably by coaching you rather than managing you. An "Agile Coach" or "Scrum Master", although not all people using those job titles are actually any good at it: 45% think they are actually a Project Manager/"boss", 45% don't do anything useful at all, the remaining 10% is what you want.

But basically someone who's job is to help you work on how you make decisions, or how you make estimates, or how you organize work. The team is still responsible for actually making decisions, estimates, etc., but the coach will help you improve.

For example, you mention consistently having wrong estimates for how long things will take. The coach might work with the team on a number of strategies here. ("You" refers to the whole team.)

1. Examining why you were wrong in your estimate. Did it actually take much longer, or were you failing to include outside interruptions (those Jira tickets)?
2. If you were just wrong in your estimate, why was that? Are you only thinking about "coding" time and not testing? Do you get requirement changes where you have to rework stuff? Is there a lot of uncertainty, surprise technological hurdles?
3. Will it be easier to estimate if you use a different technique? Breaking things into smaller pieces, using relative sizing (t-shirt sizes or story points), iterative improvements in estimates (Scrum-style).

A good agile coach will guide the team through this kind of analysis so subtly that you hardly realize they are there, so that the team creates and owns their new process...and then the coach will follow up, gently reminding people when they start to fall back into old habits. And finally, you will have iterative improvement. After some time, the team gets back together and decides if the new process is working well or still needs improvement, or what the next process to improve is.

They might also suggest starting from some framework, such as Scrum, and then help modify that over time to suit the team.

As hard as it is to find a good agile coach, a really good one is a multiplier who improves every person on the team.

Answer 10

Dude relax . Yes, you are probably falling behind but for being hired by google . There are tons of companies out there and each of them has different requirements . No, you are probably not in the mainstream software technology track but you are not far from it either. Whom are you comparing with? Plus I am sure you job has a lot of communication in it . It is just of a different nature . Define your life goals and if your track does not align with them then make the change .