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? |
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? |
Perhaps you were not a good fit there but another place you will be an amazing fit. Keep your head up.
Quality over quantity.
thanks :)
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.
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.
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.
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?
Yeah, don't sweat it. Most likely it was a cash flow problem.
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.
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?
Just look for a non-tech company, but don't expect to get to a senior level or higher.
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.
> 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
Yes, but the pay difference is real.