
Ask HN: Finding your weak spots? - jwdunne
Just wondering if anyone has any advice on finding gaps in their programming skills?<p>My mind turns back to how musicians drill repeatedly on aspects they are weak at.<p>I&#x27;m wondering: how do you find  those weak areas?
======
agitator
"You don't know what you don't know", so for me code-reviews were always
extremely beneficial. Not only getting my code reviewed, but reviewing other's
code. By getting my code reviewed, I'd be made aware of inefficiencies or
improvements that I was not aware of, and by reviewing other's code, I became
aware of techniques and strategies for writing better code. I think a social
aspect to development is very important for improvement.

Another way I have improved my coding skills in the past is to take note of
things I am unfamiliar with and look them up. A key to growth is learning new
things, so it's important to not ignore things that you don't know, but to
actually go look them up. I often go down a rabbit hole doing this, and it
takes more time, but you will learn a lot. When researching a topic or how to
do something that I don't know, if I encounter something else I am unfamiliar
with, I either look it up immediately (if it blocks the current problem I'm
on) or I make note of It and make sure to look it up afterwards. This way you
are always improving and working to fill the weaknesses in your
skills/knowledge as you come across them.

~~~
ebbv
Yep code reviews are great.

Similarly; learn new frameworks and languages. As you learn things that are
unfamiliar to you, you will start to understand why they were designed (or
evolved) that way. You can then decide whether you agree with the decisions or
not from an informed perspective.

------
astrodust
Try looking at Stack Overflow questions in a particular subject area. If you
can answer 80% you're probably on top of it. If you can answer <20% you're
probably a long way from mastering that subject and need to practice more.

Many of those questions probe really odd behaviours you'll rarely see, so
they're great training. 95% of what you do as a developer uses maybe 1-2% of
your actual knowledge. It's the remaining 5%, those ugly bugs, those quirky
edge cases, that really test you.

The more you can expose yourself to those outliers, the more quickly you can
gauge your knowledge. It helps assess if you're really good at just going
through the motions, or if you actually have a deep understanding.

------
jayec
I go about it in a bit of a round-about way. I'm a pretty introverted guy, so
I make a point to work on soft skills like communication or public speaking to
do demos. I've found that by getting out in front of others, they'll
inevitably have questions for you, some of which you can't answer. If you let
them know you'll get back to them with the answer, you become the "go to"
person and you have someone else find an area you can improve on. The more you
do this, the more you'll learn and eventually everything kind of falls into
place.

------
lozenge
Programming skills, that's great. What about your non programming skills?
Communicating, persuading, domain modelling, being able to explain your design
decisions. They can be as important as programming itself, so don't neglect
them.

~~~
hood_syntax
I'd agree particularly with domain modelling and being able to explain your
decisions. Working on those helps both technical and interpersonal aspects of
your work.

------
afarrell
One thing that is very valuable is human feedback from coworkers. However,
like most communication, there is a skill to getting and receiving feedback.
The book Thanks for the Feedback from the authors of Getting to Yes is a well-
written and presents some solid implementable ways to improve how you handle
soliciting, interpreting, and healthily responding to feedback.

[https://www.audible.co.uk/pd/Business/Thanks-for-the-
Feedbac...](https://www.audible.co.uk/pd/Business/Thanks-for-the-Feedback-
Audiobook/B014WLTBCK)

------
jmcgough
Oddly enough, I benefitted from interviews early in my career - engineers
probing for my knowledge boundaries would usually find some technical
questions where my knowledge was weak, so I'd make a mental note to learn
about that thing later.

Figuring out flaws in your development process can be harder, but it's worth
asking for coworkers/manager for insight, they can often see what you don't
even think about.

In terms of improving comfort and knowledge of new tech, I do personally
projects and try to incorporate one new tool, language or framework every
time.

------
harlanji
Cooperative coworkers who still compete in the spirit if play (Lao Tzu). HR
and the low trust/greed driven SV economy make it hard in the bay area, but
other cities like Denver and Minneapolis are where I've met best friends who
are also passionate programmers. Still looking for an answer myself locally as
I've not found many growth minded programmers who also want to/are able to
cooperate here.

Tldr: feedback, personal investment, competition

------
ozim
For instance when I started doing stuff in mvvm in WPF it was a bit tiring.
But then I also stumbled onto knockout.js and then I used mvvm in two
different ways then common patterns clicked in. If you see some improvement
area maybe try it from different angle, even better from multiple angles.

------
matt2000
I define weak spots in terms of things I'm trying to accomplish. If I'm weak
in areas I'll never need, then who cares? When trying to accomplish something
you'll find out pretty quickly the things you need to improve and be dragged
towards improving them fairly naturally.

------
bruce_the_bruce
If you are looking to advance your career, you might want to consider focusing
on understanding large scale distributed systems architecture rather than
programming.

