
Ask HN: How can I tell if I am a good developer? - detaphla
I am a software developer (paid) for about 6 years now. I basically did everything (Mainframe, Java, Frontend, Python, NodeJS...). This perfect job market made it very easy for me to transition between jobs. I did full time and contract jobs at around 6 companies.<p>Every company I stayed at wanted to extend the contract or told me I was one of their best developers they worked with.<p>However, my own perception is different. In every company I was good at creating a team spirit and to analyze problems. Every company had this one (or more) people who just coded and could put a solution into code super fast. I on the other hand sometime feel like in between.... I grasp things fast but my code was never as clean, good or delievered fast enough.<p>I wouldn&#x27;t have a problem with it if it wouldn&#x27;t be for my boredom of NodeJS. I decided to switch stacks and taught myself Go.<p>Now I got hired at a really big brand and I joined the team last month. And oh boy, these guys are good. I mean they come up with solutions I couldn&#x27;t even remotely think of.<p>I highly doubt mu abilities now and actually thinking of quitting (partly it&#x27;s hard to be a &quot;senior&quot; developer and now see how much further my team mates are).<p>The question is: How can I tell if I am good enough or doing a good job? My old projects told me I am good (enough), now they hired me and I feel like a failure.<p>Is there a way you find out where on the scale you operate? If I am too low, is there a way to get better to maybe match them one day?
======
Aeolun
If everyone around you is much better than you, and you are aware enough to
see it. Stay! This is a fantastic place to learn new things and improve your
perspective.

You may find that they’re not quite as amazing as they first seemed a few
months or year down the line. But if they are, your own progress is likely to
be much higher than at another place.

~~~
thepaulstella
This is such good advice.

As the saying goes:

'If you are the smartest person in the room, then you are in the wrong room.'

~~~
quickthrower2
Corollary: Someone in the room is in the wrong room.

~~~
randomsearch
I think this objection can be countered by completing the quote “if your goal
is to learn and grow as quickly as possible.”

Maybe the smartest person already did that, and is now more interested in
cashing in / mentoring / a quiet life etc.

~~~
quickthrower2
Yes. It was tongue in cheek. Another objection is that smartness isn’t an
ordering. You could be the best person in the room at something but still
learn on other things.

------
blablabla123
>In every company I was good at ... to analyze problems.

>Every company had this one (or more) people who just coded and could put a
solution into code super fast. ... I grasp things fast but my code was never
as clean, good or delievered fast enough.

That's the point of working in diverse teams. A few teams I have worked on
code bases that were clean as a clean room, everything solved by the books but
on a high-level flawed, with errors while running in production, hard to
maintain, modify and extend.

If you look at typical "startup code" (or "scientific code") you quickly
realize that's it's rarely that clean. On the other hand that's where the
money is at and also it can be cleaned up afterwards. From my practical
experience I can say that super clean code bases are much more static and it
takes longer times to change them.

So yeah, if you're good at analyzing stuff that's super useful. Especially if
you intend to work at more complex domains. Also I'd suggest to work with
Python, I think there a pragmatic approach is more welcomes. (Also
interesting, fairly complex stuff is done with Java at some places)

------
SiDevesh
You sound like a great developer! And being around people smarter than you and
is one the best ways to learn incredibly quick. If you feel like lacking
confidence in your skills, one thing that really helped me get over imposter
syndrome was to pick up problems or projects that I never thought I could do.
Pick up something interesting yet seemingly challenging (I was always
fascinated by operating systems and embedded hardware, so decided to make an
OS for embedded hardware). Work on it, talk about it with your peers. Once you
solve such a problem you get a big confidence boost that you can tackle any
problem out there and that on its own can help you with approaching things
without fear and solving it. Hope it helps :)

------
smacktoward
The fact that you're asking the question indicates that you are a good
developer. The bad ones don't care enough about their work to worry about it.

~~~
Aeolun
This is a great summary of all the advice given here :)

------
tinktank
A couple of points:

1) Do not compare you, after a month, with people who have been there years.
It will take time, you will get there.

2) So what if you're in-between? That's your unique selling point. Embrace,
don't discard it.

There's a place for you in your company, and in the world in general. Just
like there's a place for the coder who turns coke into code, and the marketing
exec who talks to customers. You are not a failure. Look up imposter syndrome
too. You're suffering it.

------
iamlyingman
It really depends on what you're measuring. When I think of a good developer I
just think of someone who writes clean code and organizes their program in a
way that makes sense.

A lot of people think the ability to accomplish a task quickly makes you a
good developer. This is true. But those who are strong in business knowledge
but weak in programming knowledge use this to create a false dichotomy between
quickly delivered code and poorly written code. So if the design of the
current program or business knowledge is what's slowing you down don't worry
too much about that. On the other hand if everyone on the team is doing better
than you maybe there's something they know that you don't. For example maybe
you spend more time on meaningless tasks because you don't time box. It might
definitely be worth it to check in with some other team members throughout the
day and just ask them what they would do if they were you in whatever
situation you're in right then. I found this often gives me good ideas if I
can humble myself enough to listen to them.

Try and take a step back from the situation and look at it without your ego
attached at all with respect to the goals of the business.

------
OakNinja
If you never doubt yourself, it’s probable all of the issues around you is the
fault of someone else, all conflicts is because of someone else, and if your
solution is not accepted it’s because people are not smart enough to get it.

Imposter syndrome is self reflection. Sometimes a small mistake is enough for
you to question your whole career. That’s why everyday feedback within a team
is so important. Be sure to tell people when they do great things and boost
them in what they do. Brag about your colleagues and enjoy being among people
that want to accomplish great things. Be a part of that and contribute by
being yourself :)

------
annoyingnoob
In my experience, its not good to be the smartest or most capable person in
the room. I like to surround myself with smart people that I can learn from.
I'm good at what I do but there is always room for improvement and learning
new things. Being in over your head is a good way to learn a lot, it might be
hard but you will have new skills on the other side. My advice, being willing
to fail and stick it out - you are at a point of personal gain that you don't
want to give up without failing out. Just do you best, get an A for effort.

~~~
toomuchtodo
Spot on. If you’re the smartest person in the room, you’re in the wrong room.
Failure is necessary for growth.

~~~
techslave
i like to say: our failures define us, not our successes.

~~~
toomuchtodo
I like that. Thanks for sharing.

------
jasoneckert
There are many subtle ways to tell if you are excelling at the art of
programming. For example, if you have no life, but can prove it
mathematically, then you're doing just as well as the rest of us.

------
lllr_finger
Look up imposter syndrome. You've got it, I've got it, a lot of good devs have
it.

As someone else mentioned, just being aware that you have skills at various
points of competency and you want to be better puts you in a subset of
developers that many others enjoy working with. I have personally found
success with identifying distinct skills by looking at job postings and
various taxonomies and then ranking myself on the Dreyfus model of skill
acquisition for each, then choosing where I want to improve.

The number one thing I'll always value in a developer is attitude - bringing
positive energy to the team and being willing to adapt and learn are
incredibly understated and undervalued traits.

------
busterarm
I would take a coworker that is good at helping the team "vibe" and good at
analyzing problems then the headphone wearing developer who only talks at
standup and is really fast 1000 times out of 1000.

------
six2seven
Try to release this tension a bit, stay with the team, adapt, work hard and
observe. You have now perspective after only one month. Revalidate it after 3
and then after 6 mo. And don't forget to not stop improving and adjusting.

Your story reminds me a bit of mine. I joined at some point a very skilled,
but small team of engineers working on a product from machine vision area.
Those chaps were brilliant engineers, many with significant achievements in
academic / coding championships. They were truly passionate on what they were
doing and were really good at it. And I felt that I was 'just another regular
dev' who cannot even compare with most of them, but who also liked coding and
the problems domain.

After first month working there I was quite stressed, as was I constantly
seeing the gap in my skillset, but I tried hard to manage. After 3 months, I
was slowly 'getting there', working on the full stack, but still had the
impression of vastly underperforming vs the rest of the team. After 6 months I
finally got into the rhythm and started being given more senior and
responsible tasks. It took me a while, but it was really worth it.

Although today I am working in another place (and country), but, really,
working with that skilled team was one of the most productive and self-
improving times in my career (and I still kind of miss these times and the
team).

------
schrodeenger
There are really only two ways of knowing if you're doing a good job: 1\. Your
feedback from your peers and/or managers. 2\. Your own feedback for yourself.

For #1, It seems you're getting great comments from the places you've been
providing your services, so good job there! You can keep riding on that for as
long as you're getting them.

For #2, all you need is to remind yourself of questioning if you're doing a
good job. Once you seek answers to that question (e.g. I can now play Bohemian
Rhapsody on the piano; I improved the memory/performance of that application
with great fit & finish, etc.), it will help you define your next set of
milestones (e.g. I should try to nail one of Beethoven's now; I should try to
design this other feature this other way to ace even more on the
memory/performance etc.) You'll soon find yourself questioning again and the
very act of seeking a solid next set of milestones to achieve is a sure path
to improvement.

Like someone else has commented on this thread, don't beat yourself for being
a strict self-assessor and rating yourself lower among your peers, instead a
bout of You (a month ago) Vs. You (today) would be a much more reliable
indicator of your improvements, and one that's very much within your own
control.

The very question you're asking is a proof that you are doing that exercise
fairly efficiently! :)

------
amirathi
> I highly doubt mu abilities now and actually thinking of quitting

Absolutely do not quit. You'd be amazed at how fast you become "better" when
surrounded by phenomenal teammates. Finding a team where you are in awe of
people around you is rare (even at FAANGs). Please do not squander it by
quitting. Just keep doing code reviews, design discussion & you'll quickly
level up (6 months to a year tops). Good luck!

------
jedieaston
When you are somewhere where you are learning tons and yet you aren't being
fired and your needs are being met -- you are in the right place.

------
ipnon
In a sufficiently large labor market, if you are getting paid then you are by
definition "good enough" to be a software engineer.

------
samus
I very much like your style - creating a good team spirit and analyzing
problems are underappreciated skills in our field of business. These roles
should by no means be exclusive to team leaders and analysts because they can
make all the difference in difficult projects.

Because you switched stacks, you can truly not yet be compared with the
veterans who already have vast experience with your new stack. You have to
rely on your other skills to provide value to your team. It is more important
for senior developers to understand the domain they are working in, but
eventually you will also be expected to catch up in terms of technical
knowledge.

By all means, don't quit - you are likely doing better than you think. As long
as you continue to do your best and work on improving yourself, it is your
employer's job to judge you.

------
CodeWriter23
Fast doesn’t imply good. How many regressions are the fast guys introducing?
How fragile is their code? How much are they expanding technical debt? How
well can you see any of that?

Someone else said it sounds like a great learning atmosphere, and they’re
correct. Let your new crew be your mentors. Take the best you see in them and
make it yours. Still having something to learn at 6 years isn’t a bad thing.
I’ll tell you what, anyone in the 4-10 year range who thinks they are super
expert is only deceiving themselves. Maybe if they focus in only one domain
like front end.

------
Clubber
>Now I got hired at a really big brand and I joined the team last month. And
oh boy, these guys are good. I mean they come up with solutions I couldn't
even remotely think of.

This seems to be your sticking point. The reason they can "come up" with
solutions is, in most cases, experience. They've seen those solutions before.
If not those exact solutions, the pieces of the solution, and are able to put
them all together.

Make sure you take the time to really understand their solutions so you too
can have them in your toolbox.

------
probinso
Drowning to the top is a great way to learn, always work with people who are
smarter than you. If you want to know how good you are, do volunteer teaching
at an off hours coding program.

~~~
annoyingnoob
> do volunteer teaching at an off hours coding program

This is really great advice!

------
hrgiger
There will be always better ones, in different distances, same office,
company, groups you hangout with or www. Why dont you think its an opportunity
close to you? Now you know all those solutions so why not benefit and look
forward new challenges? If you are not interested or excited with the problems
you are solving now maybe you just need a break unless they are acting you
rude its a different story. Sorry for my beautiful English:)

------
exabrial
Are you empathetic? Do you invest in others? Do you address personal bias so
you can be find common ground with those you disagree with? Quite often hn is
a popularity contest on who's using the most obscure technology to re-solve a
problem that's already well defined. Mastering these soft skills will not only
make you a better human but a great developer.

------
danShumway
Stop asking yourself this question.

I realize that's not something you can just instantly decide to do, but I
speak from personal experience -- there's no answer to "am I good" that will
leave you in a healthy place. Put as much energy as possible into erasing the
question from your mind. You do not need an answer.

Think of it this way: If you were the best programmer in the world, it would
still be advantageous for you to learn new things, and to learn from other
people. It still wouldn't be safe for you to dismiss other people's ideas out
of hand. You would still want to work on improving your own skills. There's no
such thing as a perfect programmer, so you can always go on improving.

If you were the worst programmer in the world, and you wanted to get better,
the way you would do that is by learning new things, and by learning from
other people. You would try not to dismiss other people's ideas out of hand.
You would work hard on improving your skills.

So from a personal development perspective, your relative skill to the people
around you doesn't matter, since you should be doing the same stuff
regardless. Your lifelong "job" as a programmer is not to reach some kind of
universal plateau of excellence, it is to be as good as you can be. Don't
focus on where you are. Just focus on getting better.

Outside of personal development, there are areas where evaluating your
personal skillset is valuable. However, very rarely, if ever, is that
evaluation necessary to do in absolute, generalized terms like "good" or
"bad". Very rarely is it valuable to ask, "how good am I overall?"

Valuable questions are:

"What do I still need to learn to accomplish the immediate task I want to take
on?"

"Is there someone else working on the same task that is more suited than I am
right now?"

"What is my current weakest skill, and how can I focus on improving that,
specifically?"

These are all very focused questions. They're not asking whether or not you're
"good", they're asking if you currently have the practical ability to handle
one specific thing. If someone else next to you is better suited for a task,
that doesn't mean they're a good developer and you're a bad one, it means
they're better suited for that specific task. If you decide you are best
suited to take on a specific task, it doesn't mean you're better overall than
anyone else, just that you have a unique affinity for that particular task.

In any case, most tasks are not accomplished by the people who are best suited
for them, they're accomplished by the people who take the time to sit down and
_do them_. So usually, it's only necessary to ask, "does this need to be
done?" and "can I do it?"

In terms of your workplace, the question you should be asking is not, "am I
good enough?" It's, "do these people want me?" (if they hired you and they're
not getting annoyed at you, the answer is _probably_ yes, but maybe there are
other dynamics at play). The question could also be, "is the pace at which I'm
expected to learn too high, or is the work stressful enough that I would
prefer to be somewhere else?" That's also a valid approach. Do you want to be
at your job?

But neither of those two questions have anything to do with figuring out
whether you fit into some nebulous category of "good".

This is tough to do, but from experience the best work I produce happens when
I am not thinking about my status -- when I am not thinking about whether I am
a good programmer, or a good person, or a talented artist, or anything like
that -- and instead just focusing on being the best I can be, and improving
the best I can each day. When you must evaluate your own skills, you want to
be focused. You want to ask, "what are my practical, objective, evaluable
goals, and how do I accomplish them? Where do I want to be, and how do I get
there?"

The rest is all bullcrap. It's bullcrap that is hard to get of rid of, and it
sticks in your brain and sometimes keeps you up at night. I totally get that.
But that doesn't make it any less bullcrap nonsense. Try very hard not to ask
yourself bullcrap nonsense questions.

------
wolco
Quitting is an option if you are in over your head. You may be senior but not
for that stack yet. They might have factored that in.

What most people do with your skillset is stick around and try to learn and
struggle until they make it, give it all up or move into management.

------
p0d
Sacking yourself seems like an approach :-)

------
fuzzfactor
If you serve your purpose.

------
adesode
learn from others

------
jariel
Don't compare yourself to a team of developers who have been there a while.
They're already very familiar with the patterns, idioms, operating practices.
Systems as well - so they can come with interesting iterations quickly.

Over time, if you're paying attention, I'll bet you do as well, and you
probably won't notice it when you're there because it's gradual.

'5 years in software' is really when you start to get off Of your own hill and
start to see all other mountains in the landscape, so it can be bewildering.
But it's fun.

FYI I've you've been told several times by other firms they like you - and
you've been hired by a reputable firm ... then almost assuredly you're decent.
The filters are probably not wrong.

Also - don't quit. Every time you get a promotion, it's natural to feel like a
fish out of water - it's normal to feel like you 'don't know what you're
doing' because how could you (?!?) you've never done it before! Just try to do
your best, and I'll bet in a few months you feel more comfortable.

------
stephencoyner
I am not a developer, but a founder and product designer, so take my opinion
with a grain of salt please.

From my perspective, what separates great developers from good ones is the
ability to accurately predict how long something will take to build. This
helps so so much with product development, sales etc.

You also need to be able to build things quickly and correctly, but as long as
you can say how long it will take, you're doing your team a HUGE favor.

~~~
invalidOrTaken
Unfortunately, this is only one signal among many, and it's not a reliable
one. It's like saying a good gambler is one who is lucky at the slots. Sure,
but...

You'd be better off injecting a large amount of uncertainty into your
estimates, and planning around that. If that kiboshes a project, it kiboshes
it. Better to fire your devs because you have nothing (feasible) to work on,
than to fire them three months later because the project was late, because you
have to pay them in the second scenario.

~~~
stephencoyner
Creating a large window to account for some uncertainty is fine. My main point
is in working with some less experienced engineers they'll say "This will only
take 2 days" and it takes two weeks. This kills teams.

I think less experienced people do this because they are excited / eager to
please, but it only hurts in the long run.

