Ask HN: How do I know if im a slow developer?
i got fired in 2020 march for my last job at a startup for not being fast enough.. I dont know if it was company specific or i;m legitimately slow developer. How fast and how much do you expect to work?
11 comments
I am often slower than other developers. However, I produce far fewer inconsistencies (bugs...), my code is highly reusable, and my documentation skills make it easy for someone to come behind be and know what is going on without asking any (or very few) questions.
Perhaps you were not a good fit there but another place you will be an amazing fit. Keep your head up.
Quality over quantity.
Perhaps you were not a good fit there but another place you will be an amazing fit. Keep your head up.
Quality over quantity.
do your higher ups notice you produce less bugs? is this something you communicate to others or let your actions speak themselves?
thanks :)
thanks :)
We have an internal bug reporting process where internal developers talk about why each others code isn't working for them.
Perhaps I need to add a function to accommodate a specific item we didn't anticipate. This isn't a bug.
However if I have a function that does x,y,z and it turns out it can't do z or it doesn't do y as it should then we consider this a bug. We count these numbers and we ask each other to submit something that states their logic and design process. We also consider inadequate design or lack of a process a bug as well. Poor planning.
We also track time on how long it takes us to fix these bugs and implement the original design. We also ask each other for estimates on how long it would them to implement and we build a schedule on an average of these estimates.
I just ran the query for last year. I had 1 bug each quarter. One of the developers has 178. The last hire has almost 400.
I implemented a plan to reduce draw call overhead. It took me 3 months. That was almost double what other developers estimated it would take them. So far just one issue has been reported and it was more an error using to0 few words in the code comments but I added an `assert` just to warn the developer to look at this and I also fixed the code comments and provided an example.
Edit: Yes, higher ups do and look at this quarterly and I'm not sure what they do with the info to be honest.
Perhaps I need to add a function to accommodate a specific item we didn't anticipate. This isn't a bug.
However if I have a function that does x,y,z and it turns out it can't do z or it doesn't do y as it should then we consider this a bug. We count these numbers and we ask each other to submit something that states their logic and design process. We also consider inadequate design or lack of a process a bug as well. Poor planning.
We also track time on how long it takes us to fix these bugs and implement the original design. We also ask each other for estimates on how long it would them to implement and we build a schedule on an average of these estimates.
I just ran the query for last year. I had 1 bug each quarter. One of the developers has 178. The last hire has almost 400.
I implemented a plan to reduce draw call overhead. It took me 3 months. That was almost double what other developers estimated it would take them. So far just one issue has been reported and it was more an error using to0 few words in the code comments but I added an `assert` just to warn the developer to look at this and I also fixed the code comments and provided an example.
Edit: Yes, higher ups do and look at this quarterly and I'm not sure what they do with the info to be honest.
> got fired in 2020 march for my last job at a startup
I think being March 2020 && At a Startup, are probably much more explanatory here than any reason they gave you. A lot of companies, and most startups, did substantial layoff's then don't take it personally.
There are probably things you can learn from the experience though. It's possible you were mis-aligned with what your manager wanted; maybe they wanted you to duct tape fixes ASAP & you were over-engineering a more long term elegant solution. Or maybe you just weren't great at showing the value you were contributing to the rest of the team. etc. etc.
I think being March 2020 && At a Startup, are probably much more explanatory here than any reason they gave you. A lot of companies, and most startups, did substantial layoff's then don't take it personally.
There are probably things you can learn from the experience though. It's possible you were mis-aligned with what your manager wanted; maybe they wanted you to duct tape fixes ASAP & you were over-engineering a more long term elegant solution. Or maybe you just weren't great at showing the value you were contributing to the rest of the team. etc. etc.
It depends on the project and the team/environment, but I’ve always found the old saying “slow and steady wins the race” to be true.
Better to work slowly and take the time to communicate, collab on reviews and write decent documentation than just slap things into production as quickly as possible.
Of course the company has to value that kind of approach.
Better to work slowly and take the time to communicate, collab on reviews and write decent documentation than just slap things into production as quickly as possible.
Of course the company has to value that kind of approach.
Sounds like a shitty company if they just straight out fire you because of that. They should have worked with you first, tried to identify the reason for this mismatch of expectations.
Speed depends on external factors too, did you have the resources available to succeed ? Was the problem well defined and well understood by you ? Were someone available to ask if you needed additional information? Were your manager following up on your issues? Did requirements change, was this expected and understood? Were your expectations aligned with regards to prioritizing production speed versus quality versus documentation?
Speed depends on external factors too, did you have the resources available to succeed ? Was the problem well defined and well understood by you ? Were someone available to ask if you needed additional information? Were your manager following up on your issues? Did requirements change, was this expected and understood? Were your expectations aligned with regards to prioritizing production speed versus quality versus documentation?
> 2020 march for my last job at a startup
Yeah, don't sweat it. Most likely it was a cash flow problem.
Yeah, don't sweat it. Most likely it was a cash flow problem.
Was it your first job? How did you perform compared with other developers?
Expectations vary between workplaces. This isn't a pattern until it has happened at multiple companies.
The people who have been fired from teams I've worked with have either had trouble completing tasks or been unable to collaborate with others.
Expectations vary between workplaces. This isn't a pattern until it has happened at multiple companies.
The people who have been fired from teams I've worked with have either had trouble completing tasks or been unable to collaborate with others.
no it wasnt my first job, 2 years experience.. but i feel like every time i start a job the first 2 months i get this feedback over and over. but a few months later noone has any negative feedback, what do people expect from peoples first month? feels like they expect full competency within a certain timeframe (less than a month). i have trouble finding other people expectations so dont know how to meet what i dont know
Don't worry about it then. Some people are faster at starting than others. Just do your best and don't worry about it until this happens again.
How long does it take to you to produce something? How often do you commit code? If it’s taking a long time, are you waiting to complete an entire feature from beginning to end, or do you commit along the way? Can others see your progress along the way? Do have interactions with other team members, or are you hidden away, out of sight, while others are more engaged? When you get blocked, do you ask for help? Do you take initiative to figure out what to do next, or do you rely on someone else to spoon feed you exactly what task to work on?
Did you feel like you were a good fit at that company? Whenever you were fired, was it a surprise? Did you feel like you should have been delivering more or more often, or was it a surprise?
Did you feel like you were a good fit at that company? Whenever you were fired, was it a surprise? Did you feel like you should have been delivering more or more often, or was it a surprise?
I'm a slow dev when it's something new. My company only cares about speed. I'm still a midlevel dev after 10 years and probably always will be.
Just look for a non-tech company, but don't expect to get to a senior level or higher.
Just look for a non-tech company, but don't expect to get to a senior level or higher.
This seems a bit defeatist. Have you ever inquired what qualities you're missing that are expected from a senior level dev? Because it certainly seems like you'll get a different answer depending on who you ask "what is a senior dev?". With 10 years experience I have a hard time believing it's you, and not management gatekeeping pay based on low self-confidence/assertiveness.
"This seems a bit defeatist. Have you ever inquired what qualities you're missing that are expected from a senior level dev?"
Speed. When facing lots of context switching and new stuff, I'm slower to implement because I want to have an in-depth understanding.
I filled the role of a senior dev and even a tech lead for one year each. It was a system that I became an expert in. Then they outsourced it and I had to start all over. I was pretty fast here since I knew it well. Mostly politics for why I didn't get promoted there.
On the next team I was on, I was told that they wanted more speed too. I think this was mostly that they didn't count points for security work, and that was what I did for close to 50% of my work. When I left for my current team, multiple tech leads and senior devs asked where I was going. They were shocked that it was a midlevel position and most said they thought I was already a senior dev.
Now I'm on a team with constant context switching and tech stack switching. I'm slow enough that they gave me a bad rating last year. So maybe I am a defeatist at this point. There's really no point in trying the same stuff when it's gotten me nowhere before.
Speed. When facing lots of context switching and new stuff, I'm slower to implement because I want to have an in-depth understanding.
I filled the role of a senior dev and even a tech lead for one year each. It was a system that I became an expert in. Then they outsourced it and I had to start all over. I was pretty fast here since I knew it well. Mostly politics for why I didn't get promoted there.
On the next team I was on, I was told that they wanted more speed too. I think this was mostly that they didn't count points for security work, and that was what I did for close to 50% of my work. When I left for my current team, multiple tech leads and senior devs asked where I was going. They were shocked that it was a midlevel position and most said they thought I was already a senior dev.
Now I'm on a team with constant context switching and tech stack switching. I'm slow enough that they gave me a bad rating last year. So maybe I am a defeatist at this point. There's really no point in trying the same stuff when it's gotten me nowhere before.
Well fwiw software titles are bs. I really liked this article[1] where (among other things) they say:
> The primary skill of senior engineers is to train junior engineers. If you’re senior with no junior around, you’re not senior.
and
> Under that lens, the term “junior” just means “someone who has done less, and/or has less experience with, a specific task or tasks in a specific domain”, by contrast with “senior”. In other words, junior/senior is domain-dependent and team-dependent: we can be senior in one field (e.g. databases, containers), junior in another (e.g. frontend, machine learning). We can be senior relative to one team, and junior relative to another.
To suggest that you're not a senior developer because you take you're effected negatively by a lot of context switching is just blaming your manager's problems on you. Using a situational[2] senior position, you surely would meet the requirements. Note that neither of those deal with iteration speed or context switching, what a stupid metric.
Maybe you would do better in an actual senior role where you're doing more mentoring/overseeing rather than direct coding and bouncing around in tons of different code bases.
[1]: http://jpetazzo.github.io/2018/08/15/junior-senior-mentor/
[2]: https://en.wikipedia.org/wiki/Situational_leadership_theory
> The primary skill of senior engineers is to train junior engineers. If you’re senior with no junior around, you’re not senior.
and
> Under that lens, the term “junior” just means “someone who has done less, and/or has less experience with, a specific task or tasks in a specific domain”, by contrast with “senior”. In other words, junior/senior is domain-dependent and team-dependent: we can be senior in one field (e.g. databases, containers), junior in another (e.g. frontend, machine learning). We can be senior relative to one team, and junior relative to another.
To suggest that you're not a senior developer because you take you're effected negatively by a lot of context switching is just blaming your manager's problems on you. Using a situational[2] senior position, you surely would meet the requirements. Note that neither of those deal with iteration speed or context switching, what a stupid metric.
Maybe you would do better in an actual senior role where you're doing more mentoring/overseeing rather than direct coding and bouncing around in tons of different code bases.
[1]: http://jpetazzo.github.io/2018/08/15/junior-senior-mentor/
[2]: https://en.wikipedia.org/wiki/Situational_leadership_theory
"Well fwiw software titles are bs."
Yes, but the pay difference is real.
Yes, but the pay difference is real.
Maybe you're not slow compared to other developers. Maybe they were expecting you to work lots of extra hours?
when i left they asked my friend to start working weekends, so maybe
That indicates leadership which is overstressed and has a poor understanding of the nature of software engineering productivity.
So this theory could make sense.
Some practical advice: don't take it too hard on yourself. If someone says you're slow without backing this claim with data and/or comparisons, you're slow compared to what?
Taking into account the startup context, I'd be hardly surprised if they were just trying to make you overwork.
Give some example of a task description and a timeframe that you've delivered it. Then we can estimate.
[deleted]