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.

  • 1
    Does your manager know that you had no working experience with SQL, and only learned SQL online recently ? It seems the initial 3 weeks that your manager gave you to complete the whole task too tight (for a person with no practical SLQ experience). Hopefully, you can finish the rest of the task within the next 2 weeks. Commented Jul 10, 2021 at 19:54
  • @Job_September_2020 Thank you for the response. He asked me if I knew SQL and said I did.
    – a_sid
    Commented Jul 10, 2021 at 19:55
  • 3
    Given your lack of prior familiarity with the technologies involved and your modest industrial experience overall, two weeks sounds like a preposterous estimate.
    – Steve
    Commented Jul 10, 2021 at 20:01
  • 3
    As a software engineering manager, your progress was acceptable for your skill level. However, your boss is not a software engineering manager and has no idea how long things will really take, and you seem too junior or unsure to help him understand that.
    – mxyzplk
    Commented Jul 10, 2021 at 20:32
  • 3
    The biggest problem here in other words: Manager: "Make me a sandwich". a_sid: "OK", - goes off to make a cheese sandwich, comes back later, Manager: "eww, I hate cheese! I wanted a tuna sandwich!". What to learn from that? If requirements aren't perfectly clear, If you don't know what the "Definition of Done" is, don't start working. Clear your questions first, write a concept paper, let that be approved by the manager. Depending on the project this could be a short followup mail up to a 400 pages software specification.
    – jwsc
    Commented Jul 12, 2021 at 14:19

2 Answers 2


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.

  • 1
    Thank you for the thought-provoking answer. They need to see late projects to learn when their estimates are off. If you compensate that, they don't learn. I never thought of this aspect of working over-time until you stated it in your answer.
    – a_sid
    Commented Jul 10, 2021 at 23:49
  • 3
    The principle of overtime is: Nobody thanks you for doing overtime. Ever.
    – gnasher729
    Commented Jul 10, 2021 at 23:53
  • 1
    @gnasher729 Thank you for the response. I see. I thought I would be seen as incompetent (and probably be terminated) if I do not meet objectives so I worked extra hard to finish my work.
    – a_sid
    Commented Jul 11, 2021 at 0:06
  • So was their an agreed level of polish and quality? My manager told me to explicitly state the requirements and work plan for the software AFTER I released my first version of the software. It took me 3 weeks to create the first version.
    – a_sid
    Commented Jul 11, 2021 at 2:07
  • @a_sid It is important to define the essential success of the project, and then the essential success of each "next phase" of the project. That way you know if you have passed milestones. Why even do this in versions of the complete deliverable. Odds are that 80% of your required functionality lies in about 20% of your deliverable. That should have been done 100% first, if it was an option. Start studying software engineering and development methodologies. Your boss obviously won't, and you'll need them to survive despite his efforts.
    – Edwin Buck
    Commented Jul 11, 2021 at 6:18

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.

  • Thank you for the response. 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. After how many years would you expect a developer to be able to do this?
    – a_sid
    Commented Jul 11, 2021 at 2:05
  • 1
    I would say that it's not the number of years that decides if developer can take a vague idea and run with it. It is more the developer's ability to accurately predict what the users of the product are and the ability for that developer to correctly project the user's needs into the product's functionality. Most senior developers stopped playing this game, and instead take the higher success path of just asking the users (and documenting it in some form of user story). Basically this manager's whole development process went out of style in the 90's.'
    – Edwin Buck
    Commented Jul 11, 2021 at 6:05
  • @a_sid Sorry, I forgot to answer your question. A small database of about 12 tables should be done in about four sprints of two weeks each by about four developers, provided two of them are dedicated to documentation and QA. That permits time to properly unit test the major functionality, and three points in the plan where the customer can say "that's not exactly what I wanted" Odds are you'll be done in about the same time, but the process you have used will make it harder to maintain with each passing week. Of course one can deliver with less than four, by cutting corners.
    – Edwin Buck
    Commented Jul 11, 2021 at 6:12
  • @EdwinBuck Thank you for the comprehensive response. A small database of about 12 tables should be done in about four sprints of two weeks each by about four developers, provided two of them are dedicated to documentation and QA. This certainly would have made my work a lot less stressful. It would have also allowed me to write higher quality code and more thoroughly understand C#
    – a_sid
    Commented Jul 11, 2021 at 16:00
  • 1
    @a_sid In the industry, generally speaking, junior level isn't expected to do that. Mid to senior level is. Some people get promoted to the higher levels after just a year. Some take many more. But not every company measures these things the same way (and responsibilities vary from place to place)... usually people are actually capable of doing the job a level up before they get promoted. When you are confident knowing what types of questions to ask to fill in all the blanks without being told, that's a good sign. Agree with Edwin Buck, that as you get more experienced you ASK. Not guess.
    – HenryM
    Commented Jul 11, 2021 at 17:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .