During last 3-4 years I had to end my relationship with with 3 clients/employers due to me being slow in producing code. The reason was always - I cannot deliver as much as my colleagues could or as the employer expected me to.
I am good at communication. People I work with always say I am nice to work with, adding vitality to the daily team work, but eventually things go worse as I am usually slower than my colleagues.
I sincerely love technology, web stuff, API, structuring, organising and connecting things together, but it ultimately takes more time for me to get things done than other people.
The problem is quite clear to me but I don’t see the way to improve the situation. I cannot deliver faster because I already optimise everything I can. Even during the tech interviews (one was just today) I see that I don’t achieve the expected result.
If the time pressure is lower, at the end I deliver high-quality readable code, but the time is always the part of the formula, and I understand it, because business needs everything to be delivered faster and sooner.
I feel quite sad and depressed when I see how easily and quickly my colleagues get into the problems and find solutions while I have to spend more time and as a result I question myself as a professional.
How can I improve or should I lower my expectations for the employers and look for less-demanding lower-paying clients/companies? Should I switch to some other tech area where the time to deliver is not the key factor (are there any)? May be there are techniques to improve my thought process?
Any advice is appreciated as I feel like if things keep going this way, I won’t be able to keep staying on a par with other developers around.
Look at Advent of Code, for example. I'll never, ever, finish in the top 100, if you watch the videos of people who compete at that level, you see they start writing code before they've even had time to read the entire problem.
Quality takes time. Some of us have a higher standard, below which we will not go, which makes us slower in the short run. It also makes us faster in the long run.
I'm not sure what the answer is, an came here hoping to find one, but I just wanted to say I'm glad to see I'm not the only one that faces this, and neither are you.
Since you've mentioned fullstack I guess this means you decided not to specialize. Being a little bit of everything is useful for some types of companies and work but is one source of also being inefficient. It's easier to pick frontend, backend, ops or some other specialization. Backend development is a bit more stable than FE but it depends on your taste. Having less specialities means its also easier to fit into certain job postings and crunch through the interviews but it seems to me you don't have an issue there. Being more specialized also passively makes you more efficient in that domain.
Also note that by switching jobs per year you've probably spent half of that time being onboarded. Obviously you'll be slower during the first few months at works unless you're doing something very standard and well defined. I'd also question the underperforming part. Is this due to overpromising? I've regularly worked with devs who overpromised and underdelivered. The trick here is also to properly time those estimates and take on as much work as you can carry. Note that when a company wants to get rid of you they'll always say its a competitive market or claim underdelivery but the real reasons are much more varied.
Perhaps it's worth trying to track what's the bottleneck in your workflow, compared with someone who is "faster", and then figuring out ways to remove those bottlenecks.
* Be clear about requirements. If the requirements aren’t clear push back before doing any work.
* If you are working defects expect reproduction steps, a test location, defect state, and desired state. If this isn’t clear push back on it.
* if you cannot deliver code, because the work environment is shit, then deliver better documentation.
The problems I encounter at my work is that just about every is slow. Those who aren’t appear to hoard product knowledge and are really shitty at communicating. I really want to say that is intentional behavior but I just think it’s actually a mix of shitty code, fear of writing, and aggressive posturing by people who want attention compared to everyone else. The key failure here is that the employer rewards hard work without quality checks.
- Move into leadership/mgmt? - Project management? - Product management? - Sales Engineer? - Solution Architect?
The kind of person you seem to envy are people who are most likely pattern-matching against their past experience. I attribute this quick thinking to having come across those same/similar problem statements earlier. But getting there requires a good understanding of the problem space. This can only be done by spending time in the problem space and paying attention to details.
When working on a new problem these days. I feel like I slow down too. I now tend to go for the details. What I cannot make up in speed, I make up for with detailed solutions, thinking from the user's perspective, staying aware of trade-offs, watching out for unhandled scenarios, etc.
I also document all my work. Whenever I start working on a problem/ticket/issue, I create a new note in my personal note-taking tool. I document the commands, the new findings, etc.
Fun fact: For a limited time, I fulfilled the role of a Product Manager at my recent workplace. The engineers I worked with loved the amount of detailing in my product specifications. This was the result of slowing down and paying attention to the details. The above qualities/choices also resulted in me playing the implicit role of QA for the team. The concept of "implicit roles" is explained pretty well in this blog post on the StaySassy blog [1]
I try to compensate my slowness with attention to detail, clear communication and better documentation.
Attention to detail is as good a quality as quick thinking. I like this way better.
P.S: I actually wrote a long comment in response to this thread and then turned it into a blog post for myself [2]
[1] https://staysaasy.com/management/2021/01/21/Step-Back.html