
Ask HN: As a programmer, how do you know if you're a good one or not? - dvnguyen
I always want to be a better version of myself, but it&#x27;s unclear how to quantify my quality. In sporting, there&#x27;re many stats about athletes to look at. In academia, you can look at some indirect indexes about your research quality. But as a programmer at work, I often receive feedbacks from 1 or 2 persons at most. It&#x27;s easy to think that I&#x27;m good enough, when the truth may be not.<p>So, as a programmer, how do you quantify or estimate how good you are?<p>Thank you,
======
bb88
You're asking the wrong question. You should be asking "Am I an efficient or
effective programmer?"

    
    
      Do I get things in on time / under budget?
      Do I avoid common programming pitfalls?
      Do I solve more problems than I create?
      Do I see simple solutions to complex problems?
      Can I refactor terrible code to more easily maintained code?
      Can I avoid terribly written code in the first place?
      Can I effectively communicate with people in order to get the answers I need without wasting their time with needless questions?
    

Then you know you're effective when:

    
    
      You're asked for help often.
      You're the go to person by the boss.
      You're often asked for your opinion for engineering decisions.
      Your opinion holds weight with others.

~~~
camel_gopher
One of my gotos has been 'Can I avoid writing code in the first place?'

Zero code has zero bugs, and zero maintenance cost.

~~~
gitgud
A great programmer is like a peaceful master samurai, he first tries all other
options before resorting to violence (code) he may also reduce violence (code)
where ever he goes ...

------
smilesnd
Programming is a craft once you reach a certain level their is no checklist or
metric that can be used to measure you ability. Only experience and battle
scars tell how good you might be when solving the next problem.

Only ever measure yourself against yourself. As long as you make sure you are
a better programmer today then yesterday then you have nothing to worry about.

~~~
l0b0
This. After 15 years as a professional developer I have a fairly good idea
where my boundaries are, and that's about it.

Expect to learn new things every day, and from every conceivable source: your
fellow developers, junior and senior, of course, but also your PM (for
example, prioritization, techniques to organize work), designers (information
flow, HCI), business analysts (how the client ticks), etc.. Very likely
everyone you ever worked with could teach you _something_ , and you'll never
have time to learn it all.

------
_hardwaregeek
I put in the work. I once heard a very good fencer say that the way they keep
calm during competitions is to tell themselves that they've put in the hours
of training and the blood, sweat and tears necessary to win. I spend hours of
my days writing code, reading about how to become a better programmer,
constantly analyzing my work and finding ways to improve. I'm not going to
spend my time worrying about whether I'm a good programmer. I _will_ be a good
programmer.

~~~
lolc
Hours of deliberate practice is said to be the deciding factor in how good you
are. Or at least, we can't be good without it. So yes, counting the hours we
spent writing and analyzing code gives us an idea of how good we might be as
programmers.

------
scarecrowbob
This is a general problem.

In sports, for most people, staistics are meaningless. I climb 5.10 okay... am
I good climber? I'm not world class, but I do stuff that I like.

I've been an academic. I know I was a bad one, because in retrospect I had to
step away from a lot of my ideas and research... at the end, I didn't see
value in the projects I was doing.

As a programmer... who knows. I don't usually have a lot of problems coming
back to old projects and building new stuff. I don't have a lot of systems I
put together breaking down and requiring work. I know that there are at least
10-20 other folks think I am good, because I've solved things for them and
they have told me I am good.

But I just build CRUD apps, admin some linux servers, and put together custom
code for WordPress. Some folks would look at that pile of day-to-day tech
cruft and say that I am not even a "real" programmer (even if I do know how to
implement a buffer with TTL and I've written toy mouse drivers and serial
implementations).

All that comes down to this: it really comes down to you and your goals, and
what you want to get out of your life. You are the only measure of what you
consider to be a good person. Most of us are sane enough to peg that
estimation to feedback we get from other people. But fundamentally the metrics
are still our own.

------
keithnz
Programming is an open ended non competitive (generally) activity. I don't
think there is any meaning in trying to quantify "goodness" and in fact might
blind you to possibilities.

So, for myself, the thing I pay attention to is my ease of expressing the
things I want to create. I also pay attention to my ability to produce things
with certain "qualities" correctness, simplicity, and how modular and
composable my code is. There is no objective measure of those things and my
understanding of those things constantly expands. I learn these things through
by my own experience and looking at what other people are doing and having in
depth discussions about programming ( and outside of programming ).

So I have no idea how good I am, but I have confidence in what things I can
create and confidence in my ability to learn more.

------
vi1rus
Does my code still make sense to me 6 months later?

Did I introduce new bugs?

Are people using my building blocks to add features or working around them/
redoing them?

These are not good metrics. I have researched this and it seems there is no
good way to measure coding improvement except subjective measurements.

------
hnruss
There are many ways to quantify how good of a programmer you are.

\- You can compare yourself to other developers (there are plenty of qualities
to compare)

\- You can review your statistics (commit frequency, average file size,
accuracy of time estimates)

\- You can compete in programming competitions

\- You can evaluate yourself using the Programmer Competency Matrix:
[https://sijinjoseph.com/programmer-competency-
matrix/](https://sijinjoseph.com/programmer-competency-matrix/)

Also, "Good" is subjective. Some programmers are "good" in certain contexts,
but "not good" in others.

~~~
sizeofchar
Wow, this competency matrix is very useful. Thanks for sharing!

------
rammy1234
1\. read others code. think. ask questions. why and how certain code is
written in certain way.

2\. Read more code.

3\. Write more code.

4\. If your code which you wrote few years back looks bad to you, then you are
on right path.

5\. How much you understand the core concepts. New languages and frameworks
are more of an glitter.

6\. You want to be better version of yourself, then your progess is your stats
you need look at. How many books did you read year on year? How much code you
read year on year ? How much code you wrote ? How much fun you had :)

7\. Adding, if you can think of the future maintainer of your code in mind and
code, then you are lot better than many programmers out there in business.

8\. Try to be a clean code enthusiast.

~~~
dintech
> 4\. If your code which you wrote few years back looks bad to you, then you
> are on right path.

What if the recent stuff looks bad too? :)

~~~
screaminghawk
Then why are you writing it?

~~~
sanderjd
Because you have a working, but ugly, solution to a problem and can't figure
out a solution that _does_ look good. Or because it's a trade-off: the thing
you think would be better requires more work than you think the feature is
worth. Maybe you want to tractor to make it more reusable, but decide it is
unlikely to be reused, so not worth the effort.

------
ams6110
The more experience I get, the more I realize that I'm pretty average.

~~~
finaliteration
I just purchased a coffee mug that says “World’s Okayest Developer” so I’m
right there with you.

In all seriousness, though: I’ve learned that it’s better to just accept that
sometimes you’ll do really good or exceptional work, sometimes you’ll do awful
work, and most of the time you’ll do work that’s pretty good and gets the job
done but isn’t perfect.

~~~
jfroma
I consider myself okayest because I can fix the stuff I break or improve
something I did months ago. Believe it or not, a lot of people I have worked
with can’t.

------
myWindoonn
There are no such things as good programmers. Humans have no idea how to
program computers, and anybody who tells you differently is lying.

The most honest person here is
[https://news.ycombinator.com/item?id=18538092](https://news.ycombinator.com/item?id=18538092)

------
oceanghost
If people are explaining stuff to you all the time, you're the dumbest guy in
the room.

If you're explaining stuff to people, you're the smartest guy in the room, and
you should find a place to work where you're the dumbest guy in the room.

------
spiralhead
This is a very complicated thing to answer concisely, but I'll take a stab at
it from a product development perspective.

You know you're a good programmer if the things you build "just work." It
should be near impossible to find flaws in your solutions. This is actually
rare. Most developers I've worked with will declare something "done" well
before all of the flaws have been worked out.

~~~
stcredzero
_You know you 're a good programmer if the things you build "just work."_

How do you quantify, "just works?" For a large enough project, perfection, or
even just getting pretty close to it, ends up being pretty expensive.

 _It should be near impossible to find flaws in your solutions._

I had a boss who declared he could find a bug in any page of code, so long as
you let him lawyer the specs in great enough detail. Granted, we were working
in a pretty complex domain, but as far as I could see, he was always right
about that.

As Matt Easton keeps saying: "Context!"

Maybe the company you're working for finds it much more valuable to do lots of
iterations so they can tinker with the product and keep refining it. In that
case, it might be even better than "perfection" if the things you build mostly
work, but that you can respond to change and bugfix requests quickly. (Without
introducing regressions.)

------
TamDenholm
Depends on how you measure it, if you gave me a programming test that measured
how much i knew and if i knew the intricacies of a language and memorised the
manual, while also testing me on computer science questions that only get
talked about in universities, then i'd probably perform poorly.

However, i'm a get shit done developer, while i've been doing this 14 years
and know my area very well, i dont know it nearly as well as someone who has
rigorously studied it and has been doing it for only 3-5 years. What i can do
is deliver, and thats whats valuable to businesses.

So, is "good" an academic measurement or a business one? Its all context.

------
RantyDave
Ha! So, so many definitions of good. But, at a basic level, you can boil it
down to:

* Does my code work?

* Does my code look after itself and its user when things don't go according to plan?

* Is my code simple?

* Can my code be maintained?

There are very serious sub-plots involving (ie) what does "work" mean? are
simple and maintainable the same thing? But if you hit the four points above
and don't fart in the office, you're good to go.

------
blakesterz
I knew I wasn't very good when I worked as a programmer. I based that on
watching others, and how often I could figure out problems without asking for
help. I could see I was waaaaaayyy behind even the newest people around me.
That was a long time ago, I'm still in IT, but not a coder now. I do ok with
the basics still, but I ask for help all the time.

------
octosphere
Some basic heuristics I use for determining the capability of _other
programmers_ and myself:

1.) Does the code have a good _bus factor_ i.e If the maintainer dies tomorrow
by being knocked down by a bus, can other people pick up where he/she left
off? Further research into the Bus Factor can be found here:
[https://www.youtube.com/watch?v=0SARbwvhupQ](https://www.youtube.com/watch?v=0SARbwvhupQ)

2.) Is the code well documented? This is so obvious that it is painful to
write this comment, but it is a very simple heuristic for determining
capability. Documentation can include code comments.

3.) Is the code resilient to weird input? The code should perform well under
heavy fuzzing and where possible, sanitize different input. It should be
tested against this: [https://github.com/minimaxir/big-list-of-naughty-
strings](https://github.com/minimaxir/big-list-of-naughty-strings)

------
alex-
If your employer is happy with your performance then you are probably "good
enough" as you say.

However if you truly do always want to be improving your ability as a software
engineer, then you are in luck, this field is so vast and deep that you can
easily spend more than a lifetime improving! Finding out how and measuring it
is another matter.

------
sahil-kang
I would recommend contributing code to a well known FOSS project, or at least
an existing project that you use or respect. I think hacking on meaningful
projects will be clear milestones for yourself, which seems to be what you’re
looking for.

To encourage you, here are a couple of contributions I have to Linux and
Hadoop:

_[https://github.com/torvalds/linux/commit/0bef71093d446165964...](https://github.com/torvalds/linux/commit/0bef71093d4461659643ddcef431d88a078e0407)
_[https://github.com/apache/hadoop/pull/114](https://github.com/apache/hadoop/pull/114)

If you read through the commit messages and look at the patches, I think
you’ll find that reaching these clear milestones doesn’t take an unattainable
amount of skill; just a bit of patience and curiosity.

------
sbinthree
I find as I get more experience I realize my limitations as a programmer so I
can predict much further out where I'll run into trouble. It usually ends up
being avoiding bad architectural choices, avoiding bad abstractions, avoiding
introducing bugs into code that works. It's easy to spot a bad programmer, I
find that a lot of the time a good programmer will be known for their faults
in other areas (ie. Bad communicator) but people take their skill for granted.
And then there's the rare programmer who can solve things that others can't
understand. There's way more bad programmers than star ones, but my guess is a
lot of people here fall into the good not great category unless their track
record is exceptional. A lot of people try and fail early, much like
companies, so if you've been in the game for a while it's a good indication.

------
analog31
Granted, I'm a lone wolf (mostly) scientific programmer, not a commercial
software developer. I look at a few things:

1\. Keep an eye on how big or elaborate my programs get before I lose control
of them, and have to either stop development, start from scratch, or massively
refactor in order to know what the heck is going on. Being able to maintain a
larger program, or participate in a larger project, without doing too much
damage, seems like a reasonable informal metric.

2\. Look at programs that I've written months or years ago and critique my own
work. A year-old program should hopefully look better than a decade-old
program.

3\. Try to stay abreast of improved programming techniques, incorporate them
in my work, and have faith that my programs will gradually improve.

I just realized these things are not about how good I am, but about the _rate
of change_ of my skills.

------
pdpi
Just from pure introspection, you might be able to glean an answer by thinking
about these questions:

— Are you capable of distinguishing opinion from fact? Are you capable of
distinguishing _your own_ opinion from fact?

— Any project will have easy bits and hard bits. How accurate are your
predictions of which bits are easy and which bits are hard, for projects
within your domain of expertise?

— When you think about your software, how good an idea do you have of what's
"cheap" to achieve, and what's "expensive" (e.g. which endpoints or queries
are fast and which are slow)? What's easy, what's hard? Do you understand how
the people who consume your software use it? Do you know whether common
operations for them are cheap and/or easy? Do you understand why (or why not)?

— Turn the previous question around — do you understand the design behind the
software that you consume? Are your own common operations things that are
cheap and/or easy to achieve using that software? Do you know why (not)?

— When you think of technical choices, do you tend to think in terms of
absolute right and wrong, or do you prefer thinking in terms of tradeoffs? If
the latter, how capable are you of articulating why a given tradeoff makes
sense in one situation but not another? Are the tradeoffs you consider limited
to technical matters, or do you consider "softer" aspects in your analysis
(such as recruiting costs, time to market)?

— How well do you know your tech stack of choice? How well do you understand
your own limitations within that stack? How does your stack of choice measure
up against the alternatives? Where is it better, where is it worse?

— And, finally — why does any of this matter? Do you genuinely want to work on
the sort of project that _actually_ requires so-called "rockstar" engineers,
or are you happy working on projects where good enough really is good enough?
How much effort would it take to actually become a rockstar? What would it
cost you? (you might want to go over the bit on tradeoffs above again)

------
abhayb
I believe that you get good by getting better. And I think it's easier to tell
that you've gotten better than it is to tell that you've gotten good.

Look back 6 months, a year, 2 years. How have you grown? What can you do now
that you couldn't do then? Are there things that you'd do differently? Things
you wouldn't do at all? That might give you a sense of where you are now.

Repeat the process of getting better many times. Then one day you'll take some
call, draw some diagram, write some code and you'll know. For a brief shining
moment you will know without a doubt that it is good and you are too. Then the
moment will pass and you'll spend a couple of years trying to find the next
one.

------
shay_ker
> But as a programmer at work, I often receive feedbacks from 1 or 2 persons
> at most

Oof, yeah, that's rough. It's hard to say something conclusive with little
data, and most of the data is likely biased (yourself). I'd recommend finding
opportunities to work with other devs. Open source is a good path forward.

Otherwise, estimating your performance is super hard. Are you right more often
than you're wrong? When you're wrong, do you consistently fix your flaws? Are
you learning? Are you contributing more and more business value? These are all
very opaque questions, and even if you answer all of them you're likely to
have gaps.

Get more data!

------
8bitsrule
If your code 1) runs the first time with no non-trivial errors or obvious
bugs, 2) does at least what you intended it to do, reliably, efficiently, and
isn't easily de-railed...

then you're getting close. If 3) you find you can easily and quickly modify it
to add features... months later... that's closer still.

Of course if you have to answer to someone about why you did it this way or
that way, or who can't comprehend your code, then (in that environment) you
may have farther to go.

Longer, bigger, harder projects may test your skills. Be your own best critic,
always strive to do more with less.

------
tedyoung
How do you define "good" and "quality"? This is the difficulty in measuring
skill or productivity in this kind of work. Is it the number of uncaught bugs
that have been released? How well what you produced matches with what the
askers (product mgrs, customers, etc.) asked for? How much test coverage you
have?

As others have suggested, it's useful to look at code that you wrote 3, 6, 12
months ago and ask yourself: do I understand this? Could I write it better
now? What would I do differently now? You might try keeping track of these
reflections in a journal.

------
yesenadam
Do you mean programming as a job, or programming as an activity/art? They seem
two very different things; some people are answering one or the other or a
combination.

I noticed some refer to programming as a craft - maybe programming as a job is
usually a craft. For myself, I am motivated to write a program because I don't
know what the output will be - i.e. not a craft, where the end result is known
and aimed for. It's like an experiment - it's worth doing because I don't know
what will happen.

------
andrewstuart
This can only be answered with context.

Someone may or may not be a good programmer depending on a whole bunch of
factors, the project being built, their familiarity with the codebase,
familiarity with the technologies used, how happy they feel in their job, how
happy in their personal life, if they really like the project they are working
on, whether they get time/space to concentrate. It goes on and on.

There's no answer to "is person X a good programmer" within context and even
then it's purely subjective.

------
pmoriarty
If you can manage to stay interested in what you're doing, you're going to
learn and improve over time.

If you lose the passion, and get bored with what you do, you're not going to
care, and that's a worse fate than even staying still skill-wise. It's a very
common fate for those who have to work at this 8 (or likely more) hours a day,
nearly every day of the week for years or decades.

So I'd just try to keep the flame alive, focus on always doing what you
genuinely enjoy, and not sweat the rest.

------
todd3834
My favorite definition of a “good” programmer is someone who ships! Done is
better than perfect. Knowing what compromises to make in order to ship without
creating a future nightmare.

~~~
redleggedfrog
Oh my gosh, no. That might be a "good" software developer, but I'd probably
think not on that, too.

I've had to follow behind such programmers who wrote their code with the
primary goal of getting done as fast as possible never expecting to have to
come back to it. It's literally the worst code that exists.

Usually they no longer work at the same place they created such code, because
later they were asked to maintain it. That's why I got the job. Usually we
start over.

~~~
sys_64738
The majority of software developers are payed to ship product to a deadline.
It should meet the requirements of your customers and be thoroughly tested.
There are always trade offs but the biggest impediment to shipping is the
procrastinator or the perfectionist.

If you miss deadlines then you are failing at your job.

~~~
redleggedfrog
"...the biggest impediment to shipping is the procrastinator or the
perfectionist."

I don't necessarily think that it's the "biggest" but I'll agree it's
certainly one of the problems. I think I'd put "unclear specifications" as the
biggest problem.

I've seen a lot of code delivered on time to meet the deadline that clearly
was not ready but was delivered anyway. I've never the temerity to say, "I
told you so," but I thought it. There's a balance to be had. Sometimes the
deadline and the customer requirements and future maintainability cannot all
be satisfied. Something has to give.

------
HereBeBeasties
If you work in a moderately sizeable organisation and manage to delete more
lines of code than you add, while still adding features, you may be a good
programmer.

------
core-questions
Easy, I know I'm a bad one

~~~
AnimalMuppet
If you know that, then you might be a pretty good one...

~~~
dwd
It comes back to:

"The only true wisdom is knowing that you know nothing"

Problem is - hubris is generally considered a virtue.

------
robinhowlett
It's a question I've asked myself too. I've also wondered how often others are
being aggressively pursued by former colleagues to join them at another
company. I've seen team strongly believe they hire strong candidates only, but
rarely seem to pursue these same people after moving to a new company.

------
sys_64738
Would you hire yourself?

------
koonsolo
There is no point in measuring yourself against other people, even in sports.

You should measure yourself against yourself. Your goal should be to become
your best self, not the best X in the room/world. X is mostly picked
arbitrary.

This means you should always try to become better at what you value.

------
jarfil
When you maintain a piece of code, that only you have written, for a couple of
years, and making changes to it is as easy as the first day, then you're a
good programmer.

If every change to the code feels like adding another twist to the maze, then
you're not a good programmer.

------
SubuSS
Late but we don't have stats on world's best plumber/doctor either. It becomes
a practice at one point and your results/impact becomes the true measure.

I don't think it makes sense to compare a profession to a sport.

------
empath75
If someone pays you a lot of money to program and are happy with the results.

~~~
quickthrower2
That might mean you are a good negotiator and salesman.

------
PhilipA
It isn’t about your skills now, but if you are improving. If you look back
back in code you created 6 months ago and thinks it is a disgrace, then you
are very well becoming a good developer.

------
clueless123
Somewhere I read a measure of intelligence is: the ability to achieve your
objectives efficiently. You could say the same about coding. Are you achieving
your coding objectives efficiently?

------
Ancient
Check out: [https://github.com/mtdvio/every-programmer-should-
know](https://github.com/mtdvio/every-programmer-should-know)

------
thoughtsimple
What’s a programmer?

I’m very good at breaking down old code and making it modern. Does that mean
I’m a good programmer? For that task, yes. In general, the jury is still out.

------
frob
My general rule is that if I look at code from 1 year ago and I'm not
disappointed with year-ago-me, I'm not growing as a programmer.

------
contingencies
Do you do any of the following things?

Start a project by "hitting the ground running" and writing code. Fail to
write documentation unless under external pressure. Deeply aware of the
powerful and superior features of your favorite languages. Have a considered
view that long term systems maintenance irrelevant to most software design.
Frequently roll performance optimizations in to your code.

If so, you are probably a bad programmer.

~~~
occamschainsaw
I agree on the other points. Can you elaborate on how "Deeply aware of the
powerful and superior features of your favorite languages" makes one a bad
programmer?

Not trying to be sardonic, just want to know how to improve my programming
skills.

~~~
AnimalMuppet
If you are "Deeply aware of the powerful and superior features of your
favorite languages", then you probably are too deeply caught up in language
fanboy-ism to actually understand the merits and disadvantages of your
favorite languages compared to the alternatives. (You're probably also being a
jerk to people who aren't fans of your languages.)

They're tools. They're not rock bands. Don't get caught up in fanboy-ism.

------
amriksohata
Do you solve the solution to the user's problem or just accept the solution
given by the business?

Are you a team player?

------
dsirola
Your development speed keeps being a constant even as your software evolves
and you add many new features.

------
taneq
Go back and read code you wrote 1, 2, even 5 years ago. If it's still clear
and logical, and you don't think "who's the clown that wrote this?" then
you're good. If you can hand it to someone else and _they_ don't think "who's
the clown that wrote this?" then you're _very_ good.

------
jointpdf
I wouldn't describe myself as a programmer, but I have spent a considerable
amount of time and energy thinking about how to become 'better' as a data
scientist (as well as how to encourage others to grow their skills and
knowledge, and how to measure that growth). So, I can share some tips about
learning in general (i.e. metalearning--"learning how to learn") that should
apply no matter your field. If you devote yourself to (effective) learning and
improvement, you are as 'good' as you can be, and that is what matters.

1\. People learn best by a) effortful 'doing'/practice and b) spacing that
effort out over time. (Actually, not just people...almost every organism seems
to learn more effectively this way.) Generally, the marginal benefit of
learning time is greater when you expend effort directly applying
knowledge/skill to a difficult and meaningful, rather than ingesting the
output of others. An hour spent solving programming puzzles is more effective
than reading an hour of others' puzzle solutions. 10 hours spent doing either
is better spent if it's spent as [10 x 1hrs] vs. [1 x 10hrs]. Spend more time
working on side projects that motivate you, solve book problems, solve coding
challenges, practice explaining a technical concept to someone, etc. Spend
less time gliding above the vast wilderness of what there is to know,
observing the work of others--hit the ground and blaze the trails yourself
(but don't rush it).

2\. Programming, like data science or research or basketball, is not really a
discrete skill you can directly improve at. Each is composed dozens/hundreds
of sub-skills, and mastery of the field is a lifelong endeavor of building up
these individual skills as well as connections between them. What strengths
form the core of your identity as a programmer? What about areas for
improvement? (relative to what you want to be, not compared to coworkers/HN
folks/world-experts)

3\. If you find yourself sharpening the same swords again and again (as I
have), then look for an area of both weakness and interest to reallocate
effort to. The learning benefit per unit of time is greatest when you spend it
on something in your 'zone of proximal development'\--not too easy, not too
hard, not too irrelevant, but just right. Sometimes, this may mean diving
headlong into the difficult thing you believe you "should" know, but have been
avoiding. Other times, being "better" at your field means improving at
something that seems tangential (communication/presentation, documentation
writing (!), time management, domain knowledge, mathematical skill, whatever).
Just don't fall into the trap of 'oversharpening'\--expand your arsenal.

4\. Teach/communicate what you know to others. Interact and network with
others both at, above, and below your general level of experience. This not
only helps solidify your knowledge into something permanent, but incidentally
is one of the best (only?) ways to be perceived (rightly or wrongly) as
knowledgeable. You don't even need to do this 'for real' for it to work--I
imagine myself explaining code / mathematical concepts to some imaginary
audience, whether it happens or not. And if it does, you'll be
prepared...(While backpacking in Yosemite recently, I encountered a professor
that asked me to explain a ROC curve to him. Another time, I awoke on the
train to an elderly lady, seeing the title of book that I fell asleep on,
asking me what a stochastic ["stoychistick"] process was.)

5\. Beware that the 'better' you become, the more inferior you may feel.
Climbing higher gives you an unobstructed view of the yet taller peaks in
front of you, and the canyons blocking your way. Remember to take pride in the
struggle.

~~~
methusala8
Can you add anything specific to Data Scientists in particular? I am in this
field and would like to improve further. Any pointers would be helpful. BTW,
Nice post. +1

------
austincheney
A common mistake is to judge yourself in a vacuum. You aren't a rockstar
because you have achieved a certain number of years employed (this is more
common than you would think). The Dunning-Kruger effect is very real.

[https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)

Objective measures of competence are:

* speed of delivery. Do you deliver faster than your peers?

* extreme problems. Are you able to solve problems nobody else can solve?

* originality. Are you able to demonstrate problems nobody else can see or solve problems in a new way?

* write software everybody wants. Do people frequently consume your software or beg you for certain features?

\---

Sometimes a low aggression (aggressive as far as product not angry people)
environment can trap you into a tightly contained cocoon of suck from which
there is little or no self-improvement potential. Be aware of this.

------
slavapestov
Good programmers don’t concern themselves with such trivialities.

------
ionised
If you're questioning yourself, then you're alright.

------
thdn
Try leetcode the hard ones

------
mikekchar
I can answer the specific question for you easily: you are not good enough
yet. That answer applies no matter how good you are :-) But to be serious,
it's very, very important in this industry to cultivate that attitude because
as soon as you think you are "good enough", the industry moves under your
feet. This is a job of endless learning and self development. For those that
are new to the field, take note. If you are the kind of person that just wants
to show up at their job, do what they know how to do and then go home, you are
at extreme risk to be unemployed and even unemployable in this field in about
10 years time. There is nothing inherently wrong with wanting a job like that,
but a programming job is not that (at least not right now -- maybe come back
in 20 or 30 years).

On the other hand, I could also say that no matter how bad you are, where you
are today is fine. There are so many roads in this industry it's incredible.
It is counter productive to judge yourself harshly. I know many very talented
people who I never, ever want to work with. I know very many people who don't
have so much talent that I am extremely happy to work with. I'm sure most
people can relate. No matter what kind of natural talent you have at
programming, try to cultivate the sense that others want to work with you.

I saved the most complicated bit for last. How do I know what I suck at so
that I can make sure to improve it? This is really difficult. I've seen many
people feel very secure about their abilities in one way or another, when in
reality the things they were most proud of were part of their weaknesses, not
their strengths. If I'm really, really honest with myself, I've gone through
patches of that myself. I think everybody does (although some are much more
delusional than others).

The best thing to do is to try to work with a wide variety of people who have
different backgrounds. When someone disagrees with you, make a note of it.
Even if you end up convincing them that they are wrong, try to understand
_why_ they had that idea in the first place. Is there anything you can learn?
Look for ways to invalidate your current view point.

The most difficult piece of advice to follow, I think, is to celebrate when
you are wrong. It is _easy_ to convince yourself that you are right and to put
your head in the sand. It is _difficult_ to understand that you are wrong and
to figure out how you came to your mistaken conclusions. More importantly, if
you really _are_ right, then there is nothing to learn and nowhere to grow.
It's only when you are wrong that you can make substantial progress. Cherish
that process.

One more thing: I believe that every good programmer must, at some point in
their career, build a system of significant size all by themselves. Thing of
it as your master project (the project that journeymen do to be recognised as
masters). One of the best things you can do is to build that system and
maintain it for many years. With that you can see where your weaknesses lie --
all your assumptions will be laid bare. Be very critical of the result. If it
isn't perfect, _why_ isn't it perfect. You only have yourself to blame, and
that's a wonderful piece of perspective.

