Am I too slow or are my boss' expectations high?

Question

I joined a company three and a half months ago and prior to that, I worked for another industrial automation company as a junior software engineer for one year (late 2018 to early 2020). I have a Master's degree in high performance heterogeneous computing.

I am the only software developer in my current company and two months ago, I was asked to re-create an existing database to help out a team. I was not given any explicit requirements besides being told that the new software should be more user-friendly than the older one. I used C# and SQL Server to create the software but I had no prior experience with C# and SQL Server before. I used VB.NET , WPF and Windows forms in my previous company and I found C# to be very similar to it and I learned SQL a few months ago by taking a course on Udemy. I asked my manager for three weeks to build the software and I released it after 3 weeks. My manager was not pleased with the appearance and usability of the software and told me to re-create the software in two weeks. In those two weeks, I was expected to document the software specs, create a wireframe of the software and get approval from the entire team and complete the implementation of the new software design.

In the new software, I reused many of the things I had created earlier but I was also required to do many new things which I didn't have prior experience with (creating PDF reports with SQL data, filter list-view data according to text typed by the user, store documents in the database and fetch them, CRUD operations, etc.). There are about 12 tables in the database and each table has about 6-15 entries. Given the number of things I had to learn and implement and the fact that I was building this software alone, I found two weeks to be insufficient. I had to work over-time for several days and I still couldn't complete the software but did most things. Fortunately, my manager was pleased with my efforts and gave me an additional week to have the software finished and ready for use. Two weeks later (some of my time was lost because of getting vaccinated), there are still many unfinished little things and trivial bugs in the software but the software is more or less functional.

Given my circumstances, do you think I should have finished the software within two weeks? I want to know what the general expectations are in the industry for such tasks so that I can address any shortcomings I have and position myself for a successful and long lasting career.

Answer 1

We can't tell for sure, but propably no.

12 tables with 10-15 entries means little to us. This could be highquality data with straightforward usecases, or it could be a can of worms already. Was data missing, did you have to do extra steps because of bad dataquality. Is the db scheme sound, or does it have quirks already?

Did you get clear requirements, I would say no, because you said the only thing you got was a nebulous "more userfriendly than the old". Did you have to hunt for requirements midwork, did they change?

All these are factors and more.

Relevenat xkdc here: https://xkcd.com/1425/

Users think it's easy, and they don't see hidden complexity, so estimation is hard for them. They can be way off. Even experienced engineers often have a hard time estimating, in a sense everybody sucks at estimating, some people just suck less.

Also, I presume you have no clear Definition of Done. You say you estimate you need a few weeks to finish small little things. The Pareto Principle says you get 80% of the result with 20% effort. Those 20% missing need 80% effort! It's counterintuitive, but creating the big strokes is often fast, resolving all the "little bugs" and polisihing all the small things you can improve adds up fast and takes a lot of time! More than the initial creation.

So was their an agreed level of polish and quality?

In a sense, if your manager is just there to make requests of you because he wants things, you will always get unrealistic expectations and often unclear instructions. Big companies hire people to protect the team, so they don't get dumped with unrealistic estimations and extreme pressure. These people get called team leads, lead devs, Product Owners or a thousand other titles. The exact definition depends on company. But they are in between the requesters and the doers to tell the requesters no when they come up with unrealistic stuff. It can be very though to work directly with requesters until you learn to say no gracefully.

To give you concrete advice:

Don't work overtime when given unrealistic estimates, otherwise you will work overtime all the time. This way, you deprive managers of feedback. They need to see late projects to learn when their estimates are off. If you compensate that, they don't learn. Only do overtime when explicitly ordered too.

Next, clarifiy the Definition of Done and Requirements better. You should learn about agile (Scrum/Kanban). The TLDR version for my answer here is: Do something and ask the requester regularly if you are on the right track and what you shall do next. Typical intervalls are once per 1-2 weeks.

Hopefully you will learn to manage up, meaning managing your manager (and his expecations and views) in the long run. That's something every junior has to learn, because junior you think your manager knows everything, which just isn't the case. Ideally, your manager listens, which sadly isn't always the case.

Answer 2

You weren't too slow when we consider your experience level, and the fact your boss doesn't know much about software plus didn't give you good direction to start with. Yes, your boss's expectations were too high.

"Given my circumstances, do you think I should have finished the software within two weeks?"

No. Also you don't have the experience to take a vague idea/memo like the boss gave you and run with it and do everything it takes to develop into a finished product. A more experienced developer would know how to navigate that. Even someone with many years in the industry could give a time estimate that is 2-3 times lower than reality. There's always uncertainty unless you're just doing simple maintenance tasks or cookie cutter copy & paste stuff. Probably why most companies have more than one developer too.

Don't beat yourself up too much. I'm guessing that you would be better off at a company with an engineering department and proper management. Even if they only give you small tasks for a year you'll learn a lot that's needed to move up the ladder.