
How do I know if I'm good at programming? - danielslater
http://www.danielslater.net/2017/07/how-do-i-know-if-im-good-at-programming.html
======
brightball
Does someone have a problem? Can you build a solution to that problem? If not
can you learn to build a solution to that problem? Once built, can you learn
to improve that solution?

The best advice on the profession that I was ever given was simply, "Learn to
learn."

The vast majority of this profession is just being interested in figuring out
how to solve different problems. Sometimes that means it's all you and
sometimes it means learning new things or doing research.

You know that you are not a good programmer when you don't see any problems
that need to be solved.

~~~
johnfn
In that case, what do you do?

~~~
mercer
I'd say: go look for those problems!

I'm sure others can do a better job elaborating on this process. I only
recently made a mental switch to treat programming as a thing in itself that I
enjoy, and it really has made me a happier person. I'm learning faster and
more than ever before (even with coding as my only source of income, which
should have provided incentive), I'm having an amazing time exploring things
for the sake of just exploring and learning.

And as a bonus, it has made me both enjoy and do better at my job as well! I
feel like my toolset has rapidly expanded, and as a result I can (justifiably)
use those tools to help clients (and get paid), scratch actual code-solvable
itches I've had for years, and see potential ways to generate recurring
income. And, with some trepidation, I even think I've learned at least _some_
things that I can use to 'make the world a better' place!

EDIT: more specifically, aside from looking for problems to solve, I decided
to create my own problems, or consider them worth solving, and then went and
solved them.

------
StephenMelon
There are 2 types of “good” programmers, who both think the other type is
useless.

The first is the “rockstar” developer type who is great at prototyping,
hitting deadlines no matter what and delivering functionality, albeit full of
bugs. They will write 80% of the code and will drive the support team up the
wall by breaking the build, causing customer issues in production, security
holes and basically seriously degrading the code base. But their boss will
love them because they deliver the shiny when required.

The second type are the ones who can sort out the mess created by the first
type without making things even worse. They tend to be less visible, less well
paid and less in demand but every company needs them.

The whizz kids and the grown-ups basically. Companies who only have the first
will burn bright but not be able to scale. Companies who have only the second
type tend to move too slowly to get to market or pivot.

So ideally there is a symbiotic relationship between the two types and someone
who is a combination of the two is very rare indeed, because the first either
needs an ability to place limitations on awareness of the big picture (and
it’s very difficult to create a blind spot on demand once you have experience)
or they need to be incredible at both analysis and full stack execution. Those
people are few and far between so a process that gets the best out of the two
types is, in my experience, the way that most companies work.

~~~
Johnny_Brahms
I don't know if I agree. I have friends that can smash out amazing code in
very little time.

Looking through some repositories of programs I like, some of them were
prototyped in very little time, but with a surprisingly excellent first
revision.

I had the pleasure to work with Zed Shaw quite some time ago, and even though
his code might not be perfect, he writes a lot better code than the vast
majority, in a lot less time.

~~~
DC-3
This is interesting to hear. I thought Zed's book on C programming was
reasonably good but I lost an awful lot of respect for him with his strange
and nearly incomprehensible tirades against Python 3.

~~~
zedshaw
LOL. An account with these as the only comments and no submissions? Man this
place is so weird. It's like you're at a party, and then some guy can scream
at you from across the room while wearing a Richard Nixon mask and everyone
goes "Oh yeah that _is_ true." Never questioning why the guy is wearing a mask
at a party.

Anyway, I think you need to look up the words "tirade" and "incomprehensible"

~~~
Zenbit_UX
Looks like you got some haters... The only reason to make a throw away in
order to bash you - deservedly or not I don't know - is because you know this
person and they don't want to remove their Nixon mask and risk a real life
confrontation.

tldr: Welcome to the Internet

~~~
DC-3
I did not create this account as a throwaway. I just don't have the
inclination to comment on HN much and was lurking for a long time until
recently. As proof I point you to my Reddit account of the same name which has
a great deal of activity and which is reasonably well recognised and regarded
in certain communities. I say this to demonstrate that I am not creating
burner personas for the sole purpose of starting flame wars - but I did think
it was worth stating in this discussion that Zed has succeeded in discrediting
himself in some programming circles.

------
std_throwaway
The best programmer is the one who can solve the problem effectively and
efficiently without even touching the keyboard.

You don't have to be "good". You have to solve the right problem efficiently.
Find the right problem and be the solution. If you need to write a program,
make an easy one. Easy to use and easy to maintain. You'll get what that means
after a few years of maintaining. Nobody ever cares if you're a "good
programmer" or how you feel about yourself.

~~~
fundabulousrIII
What you describe is application and systems architecture and requires domain
knowledge. Excellent programming requires the ability to create a functional
blueprint in whatever way/shape/form is decided and do so without undue time
and cost.

~~~
e12e
Maybe programming is to system architecture as tactics is to strategy. Which
would probably mean management is to system architecture as logistics is to
strategy?

~~~
fundabulousrIII
Good analogies.

------
TamDenholm
Depends how you define good. Some define good as getting the job done in a
quick and efficient manner and making the client (or company) happy with the
result, however code quality may suffer in this instance and it could be hard
to maintain. Others define good as writing the highest quality code with high
test coverage, deployment procedures, writing detailed JIRA tickets, great
documentation, training other developers in the team on the system, making the
front end pixel perfect, recommending and implementing better features and
improvements into the project, etc etc. As you can tell these people may
suffer from inability to meet deadlines and getting things out the door.

Ideally you walk the line between them both. Personally, I'm in the former
camp, but I'm more a business owner than a coder, so deliverables are more
important than the best programming methodologies. It depends on what the
priority of the business/department/team is.

~~~
nickthemagicman
Deliverables is misleading. Would you rather a deliverable full of bugs that
can't scale but is delivered 'on time'?

~~~
fragmede
Why not just build code efficiency requirements and correctness into the spec
then? Hah, I'm just kidding, I've worked long enough to know no one ever has a
spec. (I've heard things about various NASA projects but have never worked
there.)

What is this deliverable for? TechCrunch Demo? The _only_ metric a demoable
build, and even then people understand it'll have bugs.

There are still places where there's a drop dead date for code (firmware;
physical media) but continuous deployment on the web turns that on its head -
the software is constantly evolving; there's no single deliverable that's set
in stone and can never ever be changed.

Developer hours is a very limited resource, better to launch the product with
slow code and parallelize thanks to the cloud and optimize once hotspots are
identified.

"We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil." -Donald Knuth.

------
steinuil
I don't think there can be an absolute measure of how good of a programmer one
is; it is a function of how well acquainted one is with the problem at hand.

A problem is not only defined by stuff like the core routines of the program,
but also everything surrounding it, like the structure of the code and of the
program as a whole, the environment the program is supposed to be running in,
and how to collaborate or manage the other people who are working on the
program. Though at this point it's probably better to use a broader term like
"software engineer".

A programmer who has enough experience across the whole stack for a certain
problem is going to be able to deliver good, readable and efficient code in a
timely fashion.

------
debaserab2
Good programmers manage side effects. They have an idea of what kind of side
effects a particular coding strategy or pattern is going to tend to produce.
They understand the range of bugs they are likely to encounter with an
implementation and shore them up quickly.

Likewise, they also tend to produce more desirable side effects - things that
maybe weren't described in the spec but are a noticeable improvement (e.g.,
responsive UI behavior)

------
wvh
I think there are different ways to be a good programmer, beyond basic
intelligence and diligence.

In security and high-availability related environments – where I've spent most
of my time – it is important that you validate all ins and outs, system and
function returns, check if writes succeed, in short, not unlike a chess
player, to be able to fit all possible moves and scenarios that could go wrong
inside your head. You probably need to naturally possess a mind that is
precise and can find all loopholes.

Another way is to see efficiency through layers of algorithms and realities of
real-life systems. Universities focus too much on mathematical formulas in my
opinion; real systems are not clean and simple like a math function with few
variabes. To understand by experience where complex systems with remote
databases, shared disks and network can go wrong and write code that foresees,
prevents or deals with unexpected complications is an important skill that
sadly enough is hard to quantify on a resume. A lot depends on experience and
knowledge, but you need to have interest and curiosity to get there.

And finally, you have those programmers that can create a more-or-less working
mock-up in mere hours. In my experience, those are not always the people that
want to spend a year ironing out all the bugs, but it is a valuable skill to
be able to adapt and churn out something fast and iterate on it. Dare I say,
the Javascript mindset. You probably need to be pretty enthusiastic about new
technologies and quick on your feet.

To find not only a motivated person but the right "type" for a job position is
probably not an easy task, just as it is hard for a programmer to find the
right job that fits your own particular strengths and way you like to work.
You might be a good programmer, but end up in the wrong environment. If you
are a thorough and perfectionistic person, you're probably not going to be
happy in a mockup-a-day start-up.

~~~
runeks
> Universities focus too much on mathematical formulas in my opinion; real
> systems are not clean and simple like a math function with few variabes.

How many variables your functions consume depends on how much you split them
up, although you'll of course end up with thousands of functions for a real
application, if they each consume ~3 arguments. So, in other words, the
limitation is to what degree your language enables you to split up your
application in tiny, obviously simple fragments.

Mathematical functions can describe anything. Haskell consists of mathematical
functions, and is Turing-complete, and because of its purity makes it easy to
split up your functions into tiny ones (or at least sufficiently small).

For example, this[1] module is a Bitcoin payment channel server I'm writing in
Haskell. The module describes, mostly at the type-level, three different
Bitcoin networks (live, test, test-derive), and presents an interface to the
Bitcoin network, which either fetches information from the Blockchain or
deterministically derives test transactions.

Everything can be split up into tiny pieces like this, it just takes time, as
the purity prevents you from utilizing loopholes that later turn out to be
unmaintainable. It forces you to understand the essence of what you're trying
to describe, because otherwise you can't capture all the invariants properly
without too much duplicate code.

[1] [https://github.com/runeksvendsen/rbpcp-
handler/blob/master/s...](https://github.com/runeksvendsen/rbpcp-
handler/blob/master/src/RBPCP/Handler/Internal/Blockchain.hs)

~~~
wvh
I think we're talking on a different level here. I'm rather thinking about the
performance from an ops perspective. If you write highly specific code that
runs close to the processor, of course predictability improves. But if you
write a web application, possibly running in a virtualised environment, using
remote databases and other network services, good look predicting performance
to the end user. Even talking about tight loops, you simply can't predict if
it will go and stay in the processor cache in layered, multi-tenant situations
like that.

There is little correlation between theory and practice of a complex system
when it comes to performance and reliability. For example, big-O notation
tells you very little about the myriads of wonderful ways systems and networks
can crash and burn. Disks never failed in my university classes. The more you
know about the difference between a perfect theoretical system and the harsh
randomness of a real one, the foresight of experience, the better a programmer
you are, and this is not generally knowledge that comes from formal education.

In short, to be a better programmer, you need to know the difference between
the best case ideal scenario and what is actually going to happen, usually
when you least expect it...

------
bpyne
No intrinsic quality makes you a good programmer. If you enjoy it, you'll
develop solutions to problems that computers can solve. As you develop more,
you'll become better.

Along the way, you'll develop a curiosity about solutions other people
developed, so you'll read code more. Simultaneously, you'll develop curiosity
about different tools, e.g. programming languages. This will lead you to
explore them more.

It's all enjoyment feeding curiosity and lots of practice.

I'm watching my daughter's friend become a great basketball player. She's not
inherently great at the game. She loves it and practices several hours daily
in a disciplined manner. When it rains she puts on rain gear to practice. When
it snows she shovels the driveway to keep practicing. She carries a notebook
everywhere to diagram plays when she thinks of them.

Great programmers practice even when no computer is in front of them.

------
jondubois
If you produce code that works with few or no bugs and is easy for you and
your colleagues to maintain and fix, then you're good at programming.

Being a good coder is different from being a rock star coder. In fact, rock
star coders can be terrible coders and yet have large followings. Most rock
star coders became popular through blogging, tweeting, hacking and/or writing
trivial software modules that are widely used. Coders who work on difficult
problems don't usually become rock stars.

------
olavk
A good programmer always looks at the bigger picture. They understand when
SOLID is appropriate and when "worse is better". A good programmer is familiar
with the best practices and guidelines and principles, but always question
them to understand their context and limitation. A good programmer understand
that all tools and techniques are means to an end.

~~~
abalos
Great phrasing. Context is key. There are absolutely times when throwing
together a quick solution is better than seeking an optimal solution. Because
sometimes it just simply does not matter and you can spend your time working
on more impactful items.

------
smoyer
You're not good at programming - you should embrace that. I suspect many
others here hate the code they wrote 6 months ago. I find that's about the
amount of time it takes for my craft to be elevated to a new level that makes
the differences obvious.

------
andreasgonewild
It's not about being good, it's about doing your best and improving every day.
Sometimes it's about doing what others would consider bad. Pretending to be
perfect is the opposite of progress and evolution.

------
nestlequ1k
One way of many: if your applications work and are reliable, your clients are
happy and you're getting paid, you are a good programmer.

------
quadcore
You know you are a good programmer when you know what over-engineered code is.
Let me explain.

The one and only metric is: how quick do you ship. I know what you think: this
leads to unmaintainable code. That is wrong because a programmer who produce
unmaintainable code doesn't ship quickly, by definition. Thats because
programming works by iteration, and then it doesn't matter you can ship one
iteration quickly, what matters is that you ship iterations quickly, over and
over again.

Now, the game is simple, you can do two kind of mistakes: you can ship too
"quickly" by writing rushed code, or you can ship too "slowly", by writing
over-engineered code, for a given iteration. If you rush one iteration, you
will have technical debt for the next iterations, and if you over-engineer one
iteration, you are wasting time AND you are piling supposedly well written
code which has no value and gonna stand in your way on later iterations (it
always do, thats what level 2 programmers dont get). Of course, and thats the
best part, programmers in practice tend to do both mistakes, which confuses
them squared: _they have a fair amount of technical debt in an over-engineered
codebase_.

Programmers in their career though tend to first do mostly rushed code (level
1 programmers) and then they do over-engineered code for the rest of their
life (level 2 programmers). So you know you are a good programmer when you
know what over-engineered code is.

 _Is the code readable?_

Sorry this is just way to subjective. What you want is a code that's _easy-to-
learn_. The difference? Easy-to-learn is really powerful while "readable" is
not. That's because programming doesn't happen on your screen, programming
happens between your ears. But first, a spectrum again, at one end you don't
know anything about the code you have in front of you which means you cant do
nothing; at the other end, you know the whole source code in which case you
can do everything: fix, rewrite, extend, debug, run, anything.

A code that's absolutely obfuscated by all standard isnt easy-to-learn, so
dont worry, yes "readability" matters of some sort. But a super readable code
can be crap too, because it can just be as obfuscated as the former, it's just
another form of obfuscation: flood.

A code written to be easy-to-learn means it has been written to help you
getting closer to "you can do anything in the code" as quickly as possible.
And guess what, the closer and quicker you are from being able to do anything
in the code, the faster you ship. Rinse and repeat.

------
murukesh_s
Depends upon what is programming? I think it's more like painting. Are you
good at painting? How can we define it? If you know to hold a brush you are
probably a painter. Are the best artists that get paid more? Or is the ones
that are at the right place at the right time?

Back to programming, I feel that web development gets more credit, and as a
web developer I can say that most of the development is just boilerplate
configuration, made complicated by layers upon layers of unwanted but
unavoidable complexity. On the other hand system programmers and game
developers do more hardcore programming stuff, but may not be as much
recognised outside their closed community.

So in other words depending upon the domain, a good programmer might mean a
person who can figure out the configuration better and keep things nice and
tidy (read 'standard') while at some other domains it might mean hardcore
analytical capability and number crunching..

~~~
jordache
>as a web developer I can say that most of the development is just boilerplate
configuration

Um no.. what boilerplate project provides universal data management, business
logic, and performance optimization that your project needs?

------
EGreg
Good is relative. Keep improving.

Coding is not enough. Is your code maintainable, interoperable? Did you ship?

What are the priorities of the project? Is your code formally verified not to
have bugs? ETH just had such a bug. Has it been tested at scale? Twitter used
to have fail whales.

Does your product have a community? Do you manage teammates well?

People live lives, companies build products. Ask yourself, "is my company
building a good product?"

To me, someone who is "good" is just someone who has learned the language and
main paradigms / tools for it, and can pick up new stuff fast. It's like a
native speaker of English who can understand what you're saying and write a
book on a new topic that goes over well.

Good means less bugs, maintainable code and playing well with others.

------
bitwize
You don't.

But you can know if you're bad at it. It's kind of like testing and other
forms of QA in software -- usually they can attest to the _presence_ of bugs,
but not their _absence_.

If you find yourself not falling into the pitfalls of a bad programmer... odds
are you're not programming enough but if you are doing it and avoiding those
pitfalls, you have a chance at being considered good. If you have enough self-
awareness to watch out for pitfalls you might fall into and avoid them in the
future, you will become better than you are now. And that's really all I can
promise you.

------
dghughes
>Identify the knowledge you lack and seek out the most relevant resource

That can be difficult on the Web.

When learning electronics searching the Web for help quickly showed how
useless it is. There were many explanations but no teaching and often the
explanation begun at a level too far past the level of the question asked.

My guess is well over 95% of explanations I saw were just people posturing to
show off their knowledge. Wordy explanations that went on for paragraphs never
teaching just saying things.

I craved brief answers that taught not explained. I know 2+2 = 4 but how do
you know that how do I learn to know that!

~~~
joshvm
Out of interest what did you feel was lacking about electronics information
online? Personally, I've always been bothered by how scattered the information
is. One site has amazing amounts of detail on one thing, but often you have to
flick between forum threads, random repositories and blogs to solve problems.

~~~
dghughes
It seemed like every site showed you the answer but not the steps to get to it
which is useless. It seemed as though people were trying to help by giving the
answer but just giving the answer isn't helping.

The answer of one single problem is of no use. Another simple example imagine
you want to know about multiplication say 5x5 but each example tells you the
answer but not how to determine the answer. Knowing allows you to find any
problem one example done for you does not.

Sites like the stackexchange network were OK although quite a bit of posturing
as I call it and verbose rambling answers. Or worse a good tutorial but closed
for apparently no reason.

I ended up at allaboutcircuits.com it was nicely laid out and with video
tutorials. It supplemented what I was learning in class.

------
javajosh
Programming is a skill and a talent, like being a musician, chef or a
ballerina. We all have our preferences when it comes to evaluating a
performer. There are still customers in government that frown at your mac
(because only windows computers are real computers), or think less of your
skill overall because you can program in JavaScript ('not a real language').
They are idiots. But they also control the money, and they are also people who
don't understand the narrowness of their view.

Meanwhile, there are countless grateful, happy customers who think the kid who
slapped together some PHP templates hosted on a slow, insecure $2/mo shared
WordPress host is a genius rockstar. This is a more defensible position; it's
just also a landmine if the business grows a lot, because any mass of PHP has
a limit of how much complexity it can absorb before breaking.

Enterprise customers are particularly hard to generalize over, because each
enterprise's software is like a factory, where all the equipment is totally
custom made, with all kinds of quirky weirdness that _may_ be part of the
secret sauce that makes things work, and no-one really knows if it is, but
just keep things working. (Actually it may be larger than a factory, including
multiple factories and some supporting supply chains a la Shenzhen).

------
tomhallett
When people look at what you'be done and say "yeah, of course it was built
like that"

------
karllager
You are good, if you question and revisit your assumptions on a regular basis,
because you instinctively know, that there is a simpler and cleaner approach -
it is just (with good reason) buried under business matters and deadlines.

If some % of changes you make to your code are towards a simplification, I
believe you are on the right track.

Not so good programmers fix their assumptions (because they need some ground
to stand on) and then let a project ossify - these become legacy systems,
burden, technical debt, and so on.

Another angle: A good programmer will save you from problems you didn't even
know you are going to have (and you will probably never noticy it, because she
or he will have your back).

Yet another take: A good programmer will find a solution to a program which is
either perfect or not perfect but so clear, that another person can use it as
a basis for a better solution. A good programmer shortens the way to the
things you want to achieve, in any way (perfect solution, good solution and
clear problem picture, communication, better documentation, explanation, more
performance, rethinking, disruption, calm night shifts, and so on).

Besides: Programming and development is actually very hard, many brilliant and
curious minds haven't searched for another occuption after they started
programming.

------
mevile
I'm looking forward to the day when we can get over our collective need to
shore up our personal confidence. Reading through these comments might leave
someone thinking that everyone is a good programmer, that just by wanting to
learn code you're entitled to receive a participation trophy. We don't really
need to handhold people.

Did you get a computer science degree? Did you land a job at a good company to
write code after an extensive interview? Have you been able to keep that job
for a few years? Have you written code other people find valuable? Do other
engineers you respect commend you on your contributions?

If you've answered yes to all of the above or at least some then
congratulations you're a good enough programmer. If not then there's room to
grow and you can become one. Either way I laud you in your choice of career.
It's a good one, and there's no reason to be handwringing about where you fit
in the spectrum of engineering skills.

Just always be learning.

~~~
mercer
It's not just about confidence though. Yes, for some people, the question of
whether they're a good enough programmer might stem from (social) insecurity,
and I think what you're saying might be a very good answer for them.

But others, including myself, ask the question because we want to, as you say,
'always be learning'. We might be insecure, for example, about getting stuck
at some equilibrium that isn't optimal, and just fishing for where to go next.

For example, it was through similarly-themed threads on HN that I learned
about functional programming. I learned how important immutability might be,
and to try and keep my functions and methods pure, even if I'm not going all
in on the functional stuff.

Hell, even just thinking in terms of separating data from code was a
revelation that I might have missed without HN functional weenies constantly
submitting articles that boiled down to that as a point.

Anyways, not disagreeing with you necessarily, just nuancing.

------
polote
> _If a programmer can’t produce good code, they aren’t a good programmer._

Who cares about good code ? good code doesn't mean anything, the only thing
that is important is working code. If your program works but the code is not
"good" people will still use it.

A good programmer is someone who is able to write code that works

~~~
falcolas
I care about good code. A caveat: I define good code as code I can come back
to in a year and easily read and understand it.

Sure, come code you write once and never have to touch again. But that's
usually the exception; popular programs always have more feature requests and
bugs and have to keep up with the changing input/output environment. If it's
bad code it will fall behind and be forgotten, because it's just too hard to
maintain.

~~~
polote
Good code is only defined by you, you will always find "good" programmers
telling you that your code is bad.

------
d--b
I mostly disagree with the article.

> Is the code readable?

Readable code may not be good code. More readable code almost always means
less efficient code. Readability is a trade off.

> Is it easy to extend?

Changing requirements are a thing for sure. But in almost every cases I came
across, planning for shifting requirements always misses the point. It is much
better to stick to your current requirements and keep your code simple, than
introduce things that complicate your code for requirements that may or may
not happen. Extending simple code is simpler than undoing code and replace.

> Is your code efficient?

It's very hard to self determine whether one own's code is efficient. Almost
every one will think their code is efficient.

> can you write it quickly?

Again people tend to think that they are fast at writing code whatever their
actual speed.

\-- the reality is that it's really hard to qualify good or bad code. Self
assession is particularly useless.

~~~
jplasmeier
"More readable code almost always means less efficient code."

Can you give examples? I'm not sold that the "low hanging fruit" of
readability improvement (empty lines to break up "paragraphs", breaking up
unintelligible one-liners into several lines, etc.) degrades performance. My
intuition is that the compiler/interpreter ends up producing almost identical
runtime code and therefore similar performance.

Unless you mean more along the lines of expressivity (i.e Python and Ruby can
get a lot done with fewer statements compared to C), but to me this effect is
in a different category than readability.

~~~
wolfgang42
Take the following code, which I had occasion to write this morning:

    
    
        foreach (var item in items) {
            if (items.Where(item2 => item.Upc == item2.Upc).Count() != 1) {
                item.Duplicate = true;
            }
        }
    

This is the most readable and straightforward code I could come up with for
the task; it's also not particularly efficient, since it does at least twice
as many comparisons as necessary (more if there are actually duplicate items).
To make it more efficient would require extra loops and manually indexing them
to skip over comparisons that had already made; in this context I decided
against this because the performance impact was minimal since there are other
far less efficient portions of the code which would best be addressed first if
the program turns out to be too slow.

~~~
dozzie
Ever heard of these things called "hashes" a.k.a. "dictionaries"? They are
magical boxes for elements that are indexed by name. You build such a magical
box of seen elements while going through the checking loop and you get the
time complexity of O(n) or O(n log(n)) instead of your current O(n^2), so it
won't explode when you get more elements passing through the code.

Note that this was conceived in just a few minutes of reading your code,
deciphering syntax only remotely familiar, and figuring out what was it
supposed to do, all with cold start (I haven't written much today yet).
Something went wrong with your thought process.

~~~
wolfgang42
First, a small correction: the if statement in my original code can actually
be written as the following, which is what I had in the actual code:

    
    
        if (items.Count(item2 => item.Upc == item2.Upc) != 1)
    

With that correction out of the way, here's the code if I used a HashSet (you
suggest 'a. k. a. "dictionaries"' but that is slower and I don't need the
other half of the mapping which they would provide):

    
    
        var set = new HashSet<string>();
        foreach (var item in items) {
            if (set.Contains(item.Upc)) {
                item.Duplicate = true;
            } else {
                set.Add(item.Upc);
            }
        }
    

To my eye, this is _less_ readable; in addition to having twice as many lines
and an extra variable, it also takes extra work to figure out what it does;
whereas my version does exactly what it says: if the UPC appears more than
once, it marks the item as a duplicate.

For a final comparison, here's an implementation of the extra loops and manual
indexing I suggested:

    
    
        for (var i = 0; i < items.Count; i++) {
            for (var j = i + 1; j < items.Count; j++) {
                if (items[i].Upc != items[j].Upc) continue;
                items[i].Duplicate = true;
                items[j].Duplicate = true;
                break;
            }
        }
    

This isn't significantly longer than the HashSet-based version, but it is even
faster to run (I just benchmarked it) and also doesn't use an extra object
which takes memory and needs to be managed and garbage-collected later.

In conclusion, while I appreciate your suggestion for a possible alternative
implementation, I do _not_ appreciate your impugning of my abilities with the
suggestion that "something went wrong with your thought process", and implying
that I may not be aware of basic data structures.

~~~
dozzie
Dude, you're leaving O(n^2) landmines in your code and you're now justifying
them by linecount and readability (actually more like familiarity with using
sets and mappings). You have just proved my intuition about your abilities.

Not to menion that:

> you suggest 'a. k. a. "dictionaries"' but that is slower

In what way you think mappings are different in implementation than sets that
makes them slower? They only need to carry one more pointer, and you're
already writing in a language quite detached from bare metal.

One more thing, since you decided to "correct" yourself instead of letting the
mistake slip: your "working" code is _still_ wrong, unless something very
weird happens in the data (but then calling it more readable this way is
fundamentally wrong).

~~~
wolfgang42
_> Dude, you're leaving O(n^2) landmines in your code_

O(n^2) I do not dispute. "Landmines," however, I take offense at: my naive
implementation can still check 10,000 items in less than three seconds; should
this ever become a bottleneck I assure you that I will adjust the
implementation accordingly. Considering that hitting this number would require
expanding the entire company at least tenfold, and knowing how other portions
of the code work, I feel justified in saying that this is likely to be the
least of their problems.

 _> you're now justifying them by linecount and readability (actually more
like familiarity with using sets and mappings)._

The _entire point_ of this thread was justifying by readability, so yes, I am.
I'm well familiar with sets and mappings, I just don't think that they're the
best solution for this particular task.

 _> In what way you think mappings are different in implementation than sets
that makes them slower?_

I don't know the internal implementation details, but having just benchmarked
it I can tell you that Dictionary<string, Item> is roughly 8% slower than
HashSet<string> for two otherwise identical implementations of this method.

 _> You have just proved my intuition about your abilities._

Likewise. From the preceding conversation, I conclude that you are inclined to
prematurely optimize at the cost of maintainability and that you tend to look
down on and make fun of anyone who you believe knows less about a topic than
you, without taking the time to consider their point of view, or even basic
politeness. You may not think that this description accurately depicts you;
but then I don't think your opinion of me seems to be correct either.

Considering that I have now spent _far_ more time than this code will ever run
for arguing the point, I'm going to step away from this discussion now. I feel
that I have made my point; increasingly heated argument seems unlikely to
affect the outcome of the debate.

~~~
dozzie
> O(n^2) I do not dispute. "Landmines," however, I take offense at: my naive
> implementation can still check 10,000 items in less than three seconds

If you're satisfied that the loop you presented runs for a time comparable
with three seconds for merely 10000 elements, it says plenty enough about your
craft.

> [...] I can tell you that Dictionary<string, Item> is roughly 8% slower than
> HashSet<string> for two otherwise identical implementations of this method.

Ah yes, benchmark comparing non-implementation (abstract class) with an
implementation (concrete class).

> From the preceding conversation, I conclude that you are inclined to
> prematurely optimize at the cost of maintainability

No. I just tend not to leave behind ridiculous algorithms, especially when an
acceptably efficient solution is of comparable code complexity.

> [...] You may not think that this description accurately depicts you; but
> then I don't think your opinion of me seems to be correct either.

Parts of it, yes, they do match. I'm an asshole that laughs openly whenever
sees statements that look ridiculous made by somebody who considers themselves
an expert (note that it doesn't matter whether they are or are not actually an
expert). But then, it's not my code that takes three seconds to walk through
ten thousands elements when -- as napkin calculations show -- it should take
under a millisecond.

------
forgottenacc57
You're good at programming if you work hard at really learning your craft....
learning some things to deep expert level and many things to competence. So
many programmers make no determined effort to learn - they are the shit
programmers.

------
mewse
A programmer who thinks that they are good at programming is almost certainly
mistaken.

A programmer who thinks that they are bad at programming is almost certainly
correct.

On a team, one of these people is more dangerous than the other. Knowing which
is the greatest wisdom.

~~~
wu-ikkyu
What is the meaning of programming?

~~~
theonemind
Vast emptiness, nothing holy.

------
austincheney
When you solve problems other people are incapable or unwilling to solve you
may effectively label yourself as: good.

If the problem is a common one and nobody else is able to solve it people will
use your code... even if the code isn't good.

~~~
forgottenacc57
I'm not a fast programmer nor the smartest, but I am a relentless problem
solver. I'm the terminator of problem solving ..... once I get stuck into
working something out I just can't rest till I've cracked the case.

------
ziikutv
Even though by OP's criteria I am a good programmer, I still think I am
terrible compares to my manager. I want to step up. Currently at a web based
startup. What can I do to become better in terms of knowledge?

~~~
marvy
Someone has to give the obvious (possibly wrong) answer, and it might as well
be me. If you've already identified someone who you think is better than you,
why not ask how they do it?

------
dcwca
If you're asking about intrinsic ability, don't worry about it. Nobody is born
with the ability to program, it's all a matter of time invested. You need an
interest and passion, time will do the rest.

------
davidjnelson
It's too broad a question to give a definitive answer to. It depends on the
context.

If you want to generalize, follow the 80/20 rule - 20% of the effort results
in 80% of the benefit. Think like a business owner. Identify what the one or
two key metrics are and come up with ways to efficiently ship ideas to test to
improve them. Write code that is easy to test. Add high value tests. Avoid
perfectionism.

------
geekme
I would like to quote what Professor paul hegarty says in Stanford's lectures
"The most bug free code is the code that you never write"

------
nurettin
What's wrong with, you know, write correct code that is maintainable and
testable?

I've observed that especially correctness is the main line that separates a
master programmer from a mediocre one.

If you are constantly making errors and not testing properly, not checking the
integrity of your data, etc. You are just mediocre and are probably being held
at your position against your will.

------
sebringj
If you deep dive into any subject head first, all in, you tend to get pretty
decent at it but you have to have passion and grit to do that and not everyone
does. There are some people with exceptional intellect but those types are
very rare so being good is achievable for most of us but being Elon or Carmack
or Hassabis isn't.

------
quantumhobbit
Can you write fizz buzz? If yes, congratulations you are probably better than
most "software engineers".

------
andy_ppp
I think it’s consistently choosing the harder more correct path. You know you
need to refactor a piece here or name a variable consistently there, but I’m
tired, I’ll just slack off this one time... unfortunately, as I’ve proven a
few times, compound interest is a bitch.

------
zappo2938
Being good at office politics influences my programming as much as the act of
programming itself.

------
bbarn
"Programming" is easy. You pick a language, learn a set of rules, and over
time learn how to tell the machine what you want it to do in that language
fairly well.

Software development is hard. Unlike many other building tasks that humans run
into, software is rarely "done". Launch of software for most of us means the
code we've written has just been promoted to a point where now it's important,
and will likely be what we work on for the near term future.

So, what makes a good software developer? Generally, programming's the
smallest part of that puzzle. Working effectively with others ranks up there.
Business acumen. Communication skills, both written and verbally.
Understanding release cycles, revision methods, standards, etc. All the things
that developers don't want to care about because they aren't writing code,
those are the things that make good software developers.

~~~
platz
Do we need to remember the distinction between type I and type II programmers?
it sounds like we do. what you described are the type II variant. (and there
are a lot more of them).

type I = kernels, database query engine/optimizers, compiler internals. type
II = glue libraries together with a high level language to solve business
goals. type II often rely on type I's work.

~~~
bbarn
I don't agree with that distinction. The programming part of it is still easy
- even easier, I should imagine, for what you're calling the type I
programmers.

The only difference is, the type I's "business" is algorithms and
optimizations instead of yet another CRM or crunching some sales data. The
underlying science behind what they are doing with it is difficult - just like
dealing with business problems are, and most of them will succeed or fail in
their efforts for the same reasons - ability to communicate and work with
others.

------
princeb
One moment he says he asks a candidate to program something he could never
have foreseen, another moment he says the candidate should have been planning
for it.

What.

There is one rule I try to go back to, especially when work starts to pile up
and things fall by the wayside. YAGNI.

------
crispyambulance
I think the question "how do I know if I'm good at programming?" is a non-
helpful question if the ultimate goal is introspection or diagnosing
professional development. Any mentor who hears such a question should
absolutely take the time to get the asker to pull back and re-think what
they're really asking, rather than dive-in and start giving specific pseudo-
objective advice about "code".

First, it is far too broad. What does "good" mean? Good enough? The opposite
of bad? Compared to whom? And even "programming" is a ridiculously vague
thing-- everyone who has worked even a year in the SW development profession
will know that programming is only part of the job and that there are many
different roles, many different kinds of skills.

Next, what is the intent of even asking that question? What can one do with
"the answer"?

------
zepolen
To know if you're good, compare your solution/methodology/speed to others
better (or worse) than you for a certain task.

Also learning from someone better than you will help you get better at least
10x more than practicing yourself.

------
webscalist
If you're good at whiteboard programming solving well known interview
questions, you're good.

Computer science is a branch of mathematics and it is all about solving
problems on whiteboard in front of peers.

------
ensiferum
Bad programmers write crappy software. Good programmers write good software.
Master programmers solve the problems without writing any software.

------
pjwal
Quite simply, if you have the ability to look at code you wrote recently and
ask yourself, "what the hell was I thinking?"

------
billions
Satoshi Nakamoto was a good programmer. He influenced the world by speaking
through code.

------
foz
1) You ship stuff often. Programming isn't useful unless someone besides you
benefits. 2) The code you put into production is stable and doesn't require a
lot of operational work (bugs) 3) Other people can understand your code easily
and modify it when needed, without requiring long explanations from you 4) You
can work with other programmers and use best practices they recognize, and you
are also good at teaching these things

~~~
loup-vaillant
> _Programming isn 't useful unless someone besides you benefits._

I beg to differ. I did [http://loup-vaillant.fr/projects/ussm/](http://loup-
vaillant.fr/projects/ussm/) only for myself. Its release, documentation, and
the few external users multiplied its usefulness accordingly, but even if I
didn't release it, it would still be useful.

------
wolco
There isn't a good or bad programmer just various levels of skills.

------
mixandgo
If you have to ask, you're probably not :)

------
sametmax
\- It works

\- It keeps workings

\- It's not hard to explain to a new team member how

------
Animats
Not mentioned: reliability.

------
rhonda456
hey guys I was introduced to emrysghosthacker@gmail.com because i really
wanted to know what my husband has been up to lately as I seem not to be
getting his attention. Emrys was able to hack into my husband’s Facebook,
Snapchat, WhatsApp, Instagram and above all gave me full access to his mobile
phone and emails without touching the phone. I couldn't help but to introduce
him to those who have their spouse cheating on them and want to spy on them.
contact emrysghosthacker@gmail.com or wechat at emryshelp he will help you out
with any hacking related issues, tell him rhonda referred you..thank me
later.you can also contact him-+14088189369

------
Entangled
If I give you $1379.87 do you know the minimum number of notes and coins you
could get?

Then you are an excellent programmer.

~~~
throwanem
The change-making problem is trivial in US currency.

------
burstmode
If you have to ask this question, you're not good.

~~~
fulafel
Not sure I agree, some people gain confidence in a lag behind skill. But you
do have to ask this question to become good.

