
Ask HN: Maybe I kind of suck as a programmer – how do I supercharge my work? - tastyface
I&#x27;m in my late twenties and I&#x27;m having a bit of a tough time dealing with my level of programming skill.<p>Over the past 3 years, I&#x27;ve released a few apps on iOS: not bad, nothing that would amaze anyone here. The code is generally messy and horrible, rife with race conditions and barely holding together in parts. (Biggest: 30k LOC.) While I&#x27;m proud of my work — especially design-wise — I feel most of my time was spent on battling stupid bugs. I haven&#x27;t gained any specialist knowledge — just bloggable API experience. There&#x27;s nothing I could write a book about.<p>Meanwhile, when I compulsively dig through one-man frameworks like YapDatabase, Audiobus, or AudioKit, I am left in awe! They&#x27;re brimming with specialist knowledge. They&#x27;re incredibly documented and organized. Major features were added over the course of weeks! People have written books <i>about</i> these frameworks, and they were created by my peers — probably alongside other work. Same with one-man apps like Editorial, Ulysses, or GoodNotes.<p>I am utterly baffled by how knowledgeable and productive these programmers are. If I&#x27;m dealing with a new topic, it can take weeks to get a lay of the land, figure out codebase interactions, consider all the edge cases, etc. etc. But the commits for these frameworks show that the devs basically worked through their problems over mere days — to say nothing of getting the overall architecture right from the start. An object cache layer for SQL? Automatic code gen via YAML? MIDI over Wi-Fi? Audio destuttering? Pff, it took me like a month to add copy&#x2F;paste to my app!<p>I&#x27;m in need of some recalibration. Am I missing something? Is this quality of work the norm, or are these just exceptional programmers? And even if they are, how can I get closer to where they&#x27;re standing? I don&#x27;t want to wallow in my mediocrity, but the mountain looks almost insurmountable from here! No matter the financial cost or effort, I want to make amazing things that sustain me financially; but I can&#x27;t do that if it takes me ten times as long to make a polished product as another dev. How do I get good enough to consistently do work worth writing books about?
======
pavlov
For what it's worth, you're feeling the same combination of awe and doubt that
grips almost any creative practitioner at some point.

Writers realize that there are other people who can write an extremely well-
structured, gripping novel in a matter of months. Artists see their colleagues
do live drawing and suddenly understand that something that is painful and
difficult for them comes easy for these other people. (I don't have musical
talent, but I expect something similar happens there.)

Are they geniuses? Probably some are, but mostly they have just worked very
hard and built a set of habits that lets them approach creative problems with
that seeming ease.

Making software is really primarily a creative pursuit like these others -- it
just has a bit more math and a bunch more high-tolerance engineering thrown
in.

Personally I think of programming as a cross between architecture and writing:
I'm making something that has a visual presence and which end users can "live
in" or "visit" (very much like a building), but it's also a story because the
interactive medium necessarily imposes a narrative. This way of thinking helps
me figure out the elements that go into software products... But probably
everybody must find their own metaphors to make sense of what they want to do
in this field.

~~~
fornever
I wouldn't say that programming is primarily creative, at least not as an
industry activity. Development overall can be creative, but the code itself is
to a large extent utilitarian. I don't think the difference, as stated by the
poster, is creativity, but workmanship. In that sense programming is more like
a craft.

~~~
GuiA
The plan drawing and model making in architecture is to a large extent
utilitarian; would you say that architecture isn't creative?

Have you seen a sculptor at work? There is nothing inherently creative about
the hundreds of hours spent chipping away little bits of rock.

What you describe is true in any art - the macroscopic creative vision is
supported by the microscopic repetitive work.

------
endymi0n
To quote Ira Glass here: "Nobody tells this to people who are beginners, I
wish someone told me. All of us who do creative work, we get into it because
we have good taste. But there is this gap. For the first couple years you make
stuff, it’s just not that good. It’s trying to be good, it has potential, but
it’s not. But your taste, the thing that got you into the game, is still
killer. And your taste is why your work disappoints you. A lot of people never
get past this phase, they quit. Most people I know who do interesting,
creative work went through years of this. We know our work doesn’t have this
special thing that we want it to have. We all go through this. And if you are
just starting out or you are still in this phase, you gotta know its normal
and the most important thing you can do is do a lot of work. Put yourself on a
deadline so that every week you will finish one story. It is only by going
through a volume of work that you will close that gap, and your work will be
as good as your ambitions. And I took longer to figure out how to do this than
anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile.
You’ve just gotta fight your way through." Ira Glass

~~~
le-mark
This is like notch and minecraft. I was on the javagaming.org forums with
notch for many, many years playing his little games and experiments. You can't
look at the finished product and have any idea about the real work that went
into it.

------
liquidise
There are 2 things i feel correlate strongly with the best devs i know:

1\. Quantity leads to Quality. This has been written about by a number of
people and for good reason. As with any craft, quality is born from doing
something in repetition and learning from your mistakes. There is a brilliant
anecdote on this from a ceramics class of all things (
[https://blog.codinghorror.com/quantity-always-trumps-
quality...](https://blog.codinghorror.com/quantity-always-trumps-quality/) ).
So try lots of things, even if they seem silly. You'd be amazed what a
throwaway project in a language you will never again use can teach you
professionally.

2\. Be passionate about both Coding and Learning. I start to look for a new
job when 2 conditions are met. First is that i have been around long enough to
see the consequences of my stack/coding/architectural decisions. Second is
that i am no longer having "eureka" learning moments with regularity. For me,
this inflection point tends to be around 3 years with a company. It will vary
for others depending on role and willingness to branch out in your codebase.

tl;dr: Force yourself to learn regularly. Move on when you start to stagnate.
Find excuses to code things, even if they are junk. Above all: have fun.

~~~
rqebmm
I mostly agree, but I'd add an important caveat to (2): Before you go looking
for a new job because you're not being challenged, ask to work on other
projects at your current job. I've found this is a much better way to learn
new languages/stacks/architectures/patterns since you already have a lot of
the relevant tribal and contextual knowledge.

~~~
mooreds
To say nothing of the fact that at your current company you are a known
quantity, which can open doors that are simply unavailable to a candidate.

------
altitudinous
I am in my late 40's, I have been coding since I began uni in 1987, I have a
Computer Science degree. When I got out there 25+ years ago I was all about
doing things the best way, code reuse, refactor etc to get things just right.
Most younger devs are. It took so much time getting the environments perfect,
unit tests, etc. The customer paid for that, my managers must have been
tearing their hair out watching us faffing about doing crap that ultimately
didn't lead to a better experience for the customer. I am much more
experienced now and live off my own skills, I have about a dozen apps on the
iOS app store the number of users is 7 figures, they bring in good coin. The
code behind them is crap, has not been unit tested, there are not massive
build environments or anything, I don't write for reuse until I need to reuse,
I acceptance test it myself. My users love the apps. They are bug free and
reliable, and users often leave reviews to this effect. Experience is
everything. I'm old school now, back in the day live fixes to production data
were nothing, no-one would ever do that now. I met older gen devs than me,
they did not then and do not now even use source control. Yet their releases
were and still are 100% stable and bug free. They are still paid a premium for
their thoroughness. As I grow older, I see more value in keeping it simple
rather than miring down the work in process and the pressure of doing it
perfectly. There is little value in it for the customer if the dev is
experienced. And I'm happy that these premium jobs are now coming up for me.

~~~
psyc
I'm about your age, and I agree with everything here. My "process" is thinking
through problems thoroughly and being careful. I used to be able to find whole
teams full of people who worked like this, and during that time I worked on at
least 5 outrageously successful, stable products, with no automated tests and
no process other than test it manually and check it in. Eventually, time moved
on and (mostly younger) people decided that this was impossible, refactoring
without unit tests is impossible, humility demands you admit to sucking at
programming just like everybody else, etc, etc. So now I mostly avoid working
at companies at all, because I can no longer find teams that don't pour 80% of
their energy into processes and methodologies.

~~~
eeZah7Ux
> My "process" is thinking through problems thoroughly and being careful.

I'm saddened by how thinking has become strangely uncommon. I've seen many
teams where people either type code or have quick chats where they decide what
to do on a whim.

~~~
mannykannot
It bugs me as well. The problem is that while 'just do it' is intuitively
appealing, thinking things through is a discipline that needs to be actively
chosen and learned, but who is teaching that? You don't have to spend much
time in the software development blogosphere to see that there are quite a few
people who seem to believe that thinking ahead is waterfall is anathema. This
may not be a proper interpretation of Agile/TDD (I could argue otherwise), but
it seems to be a fairly common one.

For the OP, I would say the point is to be skeptical of dogmatic claims about
the proper way to develop software.

------
krat0sprakhar
While this doesn't directly answer your question, but I've found edw519 (a
fellow HNer's) past comments on this subject highly enlightening.

If you're looking for something inspiring / actionable to read, checkout this
collection by him
[http://v25media.s3.amazonaws.com/edw519_mod.html](http://v25media.s3.amazonaws.com/edw519_mod.html)

One of my favorite answers -

 _71\. How do you get good at programming?

I believe that there are two ways to get good at anything, "push" and "pull".

Push: You learn from books, classes, mentors, and studying examples, then
apply what you have learned.

Pull: You have a problem that you must solve, then you learn what you need,
any way you can, to build the solution.

I suppose there are pros and cons of each method, and I imagine that many
people here have used some of both.

For the record, I am 100% Pull. I have absolutely no formal training. It took
me 2 years to find my first job and then I was thrown into the deep end. It
was simultaneously frustrating and exhilarating. There were so many times I
didn't know what to do or didn't have enough "tools" in my box. So I had to
figure it out and find sources of learning. But I always did. Any when I got
that first thing working and then saw my customer's eyes light up, I was
hooked.

Your CS degree may make you think that you're a "push" learner, but may I
suggest that you adopt a "pull" approach. Forget what you think you know and
find a job or a project or someone who has a real need. Then build what you
need. You a several advantages over me: (a) It shouldn't take you long to find
that job/demand/customer. Just keep looking. (b) You already have tools in
your tool box, maybe not the right ones for the job, but you have "something".
And (c) It's easier than ever to adopt a "pull" approach. Help is everywhere.

You may feel frustrated, but I don't think you have a problem at all. You're
in a great (and very normal) situation. Just adjust you attitude, find
something to build, and do it._

~~~
pavlov
Wow, excellent answer.

I would add that if you're a "pull" person, don't bother applying to the
Googles and Facebooks of this world. Their hiring process is extremely
oriented towards "push" learners, presumably because you need lots of those
people to build something at that enormous scale.

Instead look for opportunities where you get to do something you don't really
know how to do. (There's a number of reasons why people would let you do that,
but often it comes down to being in the right place and being patient.) That's
how you grow, not by memorizing data structure answers from "Cracking the Code
Interview".

(I know, dissing the tech interview is a HN cliché... But young people seem to
attach unwarranted amounts of self-worth to how well they do at interviews at
the Top 4 companies, so it's worth reminding that it's really not meant for
everyone and you can do well without passing that standard.)

~~~
mseebach
I'm a pull engineer, and I work for a big, recognisable SV firm. I agree that
hiring is fairly heavily biased towards push-types, but if you accept the
premise and spend some quality time with some text books and online classes,
you can come a long way (think of it as pull: if the goal is to work for
Google, this is probably what you need to do).

One thing is for certain, carrying around a chip on your shoulder because you
didn't go to Stanford will do you absolutely no good, and probably be a net
negative for your career (and happiness in general).

For the record, no, working for Google and Facebook isn't the single only
answer to life, the universe and everything, there are plenty of perfectly
worthy paths that don't lead anywhere near them, and there's no shame in
taking them. But they are juggernauts of our industry, they do pay very well,
and for better or for worse, a stint at one of them does open a lot of doors.

~~~
pavlov
Undoubtedly. A stint in the Navy can be very helpful if you plan to be a
pirate.

~~~
mseebach
A stint in the Navy can be very helpful for a great many other things, too,
and it will do you no good to tell yourself that you can never join the Navy
because you grew up on the wrong side of the tracks, even if it does mean you
may have to do some things differently.

~~~
karmajunkie
Indeed, growing up on a pirate ship might make one an excellent sailor in the
Navy as well.

------
lostcolony
So one thing I don't see a lot of responses calling out, that I think is worth
calling out, is what you see is how long the -code- took. You don't see how
long the design took. You assume it started when the code did, but that may
not actually be the case. These other developers may have had this idea in the
back of their mind for months, chewing it over, thinking about how they'd
approach something, doing research in their spare time, etc, before finally
sitting down to code it. Same with feature extensions; they likely had a
feature request, or the idea, and thought about it long before they coded it.

So if you're comparing hobby projects, things that you started working on
within a day or two of having the idea...well, maybe that's part of it, too.

~~~
enraged_camel
Furthermore, there is no way of knowing whether the code you see is version 1
or version 10. Maybe they hammered away at local copies for months before
finally figuring out the optimal design.

~~~
harperlee
Well the OP explicitly mentions that he has been looking at the timeline
between commits, so that point is moot. Even if some commits are missing, you
can see the rate of change of the project - "invisible" offline commits would
have a noticeable impact on the productivity of the "visible" one s in
parallel.

~~~
enraged_camel
>>Well the OP explicitly mentions that he has been looking at the timeline
between commits, so that point is moot.

My point is that he can't see the commits on the developer's _local_
repositories. You know, the ones they never upload to Github.

------
trustfundbaby
You're not missing anything. It starts out that (code is crap) and you just
get better the more stuff you write , and even then you never quite feel like
you're writing "good code".

The biggest thing that accelerated my growth was working with people who were
much much better than I was. You'll learn so much faster, and become so much
better than you can ever by just plugging away by yourself.

Just remain humble and open to learning and you'll wake up one day and realize
you're actually not bad at this programming thing ;)

"Better than a thousand days of diligent study is one day with a great
teacher"

– Japanese Proverb

~~~
lettergram
Second this, I also suggest trying to drop a project for three to six months
then come back to it. You'll start learning to document things and where you
went wrong. It's all about a feedback loop

------
wolfspider
I have a simpler explanation for this feeling- it's just that time of year
again. Judging by the other responses it's just on everyone's minds. We can
all look back and take stock of what we accomplished throughout the year and
feel like we could have done more, could have done it better. When I'm bored I
like to window shop cheap used cars on CraigsList. I think to myself "No one
sees what I see in this beauty- if it was mine I'd be so happy". Code can be
the same way and it seems like if it was yours it would be a new lease on
life. The code may be found in the darkest corners of the internet so
neglected but so much potential. Recognize in that moment you are creating
your "style" your "way" of creating the inspiration which is really the goal.
It's not about personal worth it's really about feeling free to create.
Developers are their most creative selves when they are happy so...my first
suspect in finding the path to developer enlightenment is environmental
factors. Development IDE? Workspace area? Skipping breakfast? Look at these
things with objective eyes then try to improve them then try again. Merging
all of this with financial concerns is going to wire your brain's reward
system up for self defeat- gain the freedom first then the money.

------
abc_lisper
You may be right. You are missing something.

The way to build big things is to build small things right. Small
functions/classes that work correctly, no matter the input. Next up, you wield
them to build up a layer and so on. Long story short, you may be missing the
concept of abstraction. I say that because you mentioned code interactions;
that tells me you are looking at things so closely, the bigger picture seems
much larger than it is.

Also, understand that people have different perspectives; that they came up
because of some random events. It is a mistake to think people who do a lot of
work, think a lot. They don't - They usually have a simpler/more powerful
perspective than you have ie, they refactored the thinking required to do a
job into smaller number of steps. This is what chess players or the
mathematicians do.

Also, you may be aiming too high without background knowledge. An object cache
layer for SQL? \- Who said this was easy?

Automatic code gen via YAML? \- Did you write a toy interpreter before?

MIDI over Wi-Fi? Audio destuttering? \- I don't even know what those mean, and
Im working as a programmer for more than 10 years, and now in a "big" company.

Do you read a lot? Many of the successful people (coding or other fields) do

May be you can start by reading SICP. It certainly cleared a lot of cobwebs
for me.

------
mamcx
Do you know when some naive people claim that build a "simple CRUD app" is
easy, but a OS or a Database engine or a Game engine or Language or Super-
Cool-Algo_performace-magnificence or Super-Science-thingy is hard?

All of them are super-wrong.

All of them are long, hard projects. All of them requiere specific skills,
that maybe are hard to know because you don't find much info about how do them
(for example, I haven't find good enough, simple material in how build a
relational engine).

But do it are easy. Because the "science" behind them is more SETTLED. Is just
niche.

> YapDatabase, Audiobus, or AudioKit

I don't know them, but it look the same as the things I'm talking about. I
LOVED to have the time or funding to devote to this kind of projects and
living from them (ie: I want to build a relational language.)

IN CONTRAST

The most "simple" apps, are HARD TO DO.

Them are easy projects, but DO THEM is harder. The specs are unclear, you
can't rely in a cool algo that solve most of it, you can't relly in a big,
large, solid foundation, you NEED TO BUILD AND PULL from several sources in
how do them.

Rocket Science is "solved", but you can waste months trying to finally know
what the hell is necessary to build that e-commerce website.

Just look at the madness with JS. Is now easier doing assembler than that.

\----

So, I mean that the human factors are the uncertain nature of most software
projects are a higher burden that the actual "hard" projects.

~~~
bmh100
What do you mean by "relational language"? I'm imagining SQL when you say
that, but I guess you have something different in mind. You've piqued my
interest.

~~~
mamcx
This is probably the most clear example of that:

[http://www.try-alf.org/blog/2013-10-21-relations-as-first-
cl...](http://www.try-alf.org/blog/2013-10-21-relations-as-first-class-
citizen)

Before I found this, most talk was at the more theoretical level and about:

[https://en.wikipedia.org/wiki/The_Third_Manifesto](https://en.wikipedia.org/wiki/The_Third_Manifesto)

\----

However, I learn first FoxPro. Is more closer to my own idea (in fact, is what
I'm after!) because is practical and is proven... yet the xbase family of
languages fade in obscurity for weird reasons
([http://wiki.c2.com/?ExBase](http://wiki.c2.com/?ExBase) talk about some and
MS killing both Visual Basic and Visual FoxPro because .NET, making the the
death of the most popular and practical) without any modern undertaking.

This make a huge community of developers that, I suspect, left the market
(without citation because is my experience in my local market) because more
"normal" languages are not as appealing as database-oriented languages. In
fact, despite I love python/delphi as the most productive languages I have
used, none is closer to Fox in the area of database-based apps. Is just
another league.

------
rubicon33
Passion.

It sounds too simple, but it's true. My best, most thoughtful, and beautiful
work, has been done when I've been intrinsically motivated by the sheer
interest and desire to do that work.

In some ways, I was a better, faster, smarter programmer, with 3 months of
experience than I am now.

That's not objectively true, but the point remains valid. If you're
struggling, you may need to re-ignite that fire. Try and remind yourself why
you got into this in the first place. Stop worrying about how you compare to
other people, and start building something that excites you. Flow.

~~~
spacemanmatt
Seconded. My best architecture work has been informed by my experience in
implementation, and vice-versa. Therein lay the art.

------
westurner
For identifying strengths and weaknesses: "Programmer Competency Matrix":

\- [http://sijinjoseph.com/programmer-competency-
matrix/](http://sijinjoseph.com/programmer-competency-matrix/)

\- [https://competency-checklist.appspot.com/](https://competency-
checklist.appspot.com/)

\- [https://github.com/hltbra/programmer-competency-
checklist](https://github.com/hltbra/programmer-competency-checklist)

... from: [https://wrdrd.com/docs/consulting/software-
development#compu...](https://wrdrd.com/docs/consulting/software-
development#computer-science-curricula) )

> How do I get good enough to consistently do work worth writing books about?

\- These are great reads: "The Architecture of Open Source Applications"
[http://aosabook.org/en/](http://aosabook.org/en/)

\- TDD.

------
tpae
I used to be like you, until I went back to the basics. Elon Musk once said,
you must master of the basics, which becomes the foundation of which you build
your knowledge. If your foundation is weak, there's going to be hard limits to
your knowledge.

I've been re-writing basic algos from scratch, and eventually more complex
ones (Dijkstras, Graphs, and etc.), and understanding CS fundamentals helped
me get past this hurdle.

------
kfrzcode
Hey tastyface. I feel you. I'm here. I didn't graduate from college, and my
knowledge is ad-hoc, learned-by-doing and incomplete. I told myself I wouldn't
give up until I was making a living writing code. I'm doing that, and it's
been arduous, but I've never been more intellectually fulfilled.

It's scary, to think there's a whole new generation of programmers who
probably can learn faster and more fully internalize algorithms and data
structures and design patterns... but we can all keep learning. There's no
limit to how much you can learn in this field, so to supercharge your work the
answer is simple: work 80-100 hour weeks like Elon, but make sure you're
actually producing at least 80% of those hours.. meaning, writing and creating
code not just reading or consuming knowledge. I don't know how many people
I've met that assume poking around reddit, HN or s/o means "working." Those
people will never outshine you if you continuously push your limits and are
always feeling in awe. That means you're on to something.

Keep it up, you're doing exactly what you should be doing - reflecting.

~~~
autotune
Working 80-100 hour weeks will almost definitely lead to burnout, or any other
number of problems that result from not being able to take a break from the
work.

~~~
Ronin354
If this is the case how does elon musk survive. I think people working for
elon also does same

~~~
Anasufovic
80 hours of coding vs 80 hours of managing companies is different.

------
Todd
First, you're comparing two different domains. App developers (whether mobile,
web, or some other environment) live at the top of the stack. As such, they
must wrangle many disparate frameworks and libraries to achieve their goals.
Framework developers can focus on a narrower set of concerns--albeit sometimes
quite deep.

I would suggest that you stop comparing yourself to them and their
achievements. Rather, use their example as a starting point in your pursuit of
improvement.

Many others offer good advice here, but one of the cornerstones is to look at
what others are doing--often and deeply. Many have asked, "How do I become a
great writer?" The answer invariably is, you must be a great reader. You need
to read A LOT.

The same goes for math. You must solve problems. That's the other half of the
coin. You need to do. So pick a problem that hasn't been addressed. Maybe
there's something you haven't found a library or framework for. Take the
opportunity to build it, package it, and open source it. You'll see that the
set of concerns is different from that of an app developer.

Edit: typo

------
Kaizyn
See Norvig's Teach Yourself Programming in Ten Years:
[http://norvig.com/21-days.html](http://norvig.com/21-days.html)

Keep in mind also there's a difference between a full stack app and a focused
framework. With the end-to-end app, you have to solve many different kinds of
problems spanning many domains. Therefore your learning curve to start is
going to be a bit higher due simply to there being more ground to cover.

To get better, you need to write more code and to study architecture of other
systems. The collection Architecture of Open Source Applications is a good
place to start reading.

With all this said, don't beat yourself up too badly. Facebook has been making
changes to mercurial version control to make it scale to work for their whole
organization. They chose the less popular vcs because the code of git isn't
organised very well and it was too difficult for them to extend/modify it.

------
jakobegger
> The code is generally messy and horrible, rife with race conditions and
> barely holding together in parts.

Writing robust asynchronous code is very, very hard. My biggest mistake as as
a beginner was that in the early days I just made up all my multithreading
stuff on the spot. I made a synchronous prototype, and thought, perfect, now I
just need to make it asynchronous.

Now I understand that "making it asynchronous" is more work than coming up
with the initial implementation, and spend a lot more time on that.

I spend a lot more time on planning in general. I sometimes think about
features for weeks or months before I start programming. I'll read all the
relevant API docs, search Google to see if other people have implemented
similar things before, etc.

Only then, when I'm well-prepared, I actually start coding. And the actual
writing is usually pretty quick, but it needed a lot of (invisible)
preparation time to get there...

------
manmal
I also do iOS apps, and I think the reason for bugs and low maintainability in
our domain (i.e. programs that have to power a GUI and all its states) is
convoluted state. You stack feature upon feature, and once the system gets big
enough, it's getting hard to get a proper grip of what is actually happening.
So you start monkey patching, and you start to regret not having written any
integration tests that would tell you when you introduce regressions.

State has to be managed rigidly. If you cannot deduce what semantic state your
app is in while you debug, then chances are things will go wrong.

I have found two approaches that work for me: Reactive programming, and good
old state machines. The former is needed when there is so much state that the
latter would be too complex (too many possible permutations > too many states
to grasp).

Every property that your screen has (element A is hidden, element B has this
text, animation C is in flight...) should be derived from the current screen's
state machine or stream of values. Meaning, state 1 will set A to hidden, B
has no text, and C is stopped; state 2 will set A to not-hidden, B has text
"xyz" and C is still stopped, etc. It's kind of like React, but on a lower
level - properties are overridden or methods are called when transitioning
between states. One could call this state machine "ViewModel" :) Swift brought
us Enums with attached values, so they are perfect for modeling a state
machine. IMO Optionals also prevent some state sloppiness we had with Obj-C's
nil behavior.

I'm not saying state machines or Reactive programming are a panacea, but they
have solved the problem for me. I'm confident in my code now, and have the
feeling that I do solid work (which is good as I'm huge on feeling like an
imposter). As long as I use Swift and RAC or state machines, the very most
bugs I cause are of semantic nature - e.g. a button text is wrong in such and
such state. But crashes or unreproducible behavior are really rare now.

------
Jach
Work with other people. Preferably a mix of people who seem less/equal/more
capable than you are, but if you have to pick one, go with working with people
that are above your level. Look at how they work, how they approach problems.
Get code reviews from them, and review their code.

Don't get set in your ways (or the ways of those better than you), be willing
to try new things and see if it fits your style.

Go slow before you go fast. It took you a month to add copy/paste -- so what?
Next time, put in extra effort to try new ways of working, playing with the
code, writing invisible support code no one else will see, writing tests
perhaps, writing English before code, getting feedback, etc., instead of what
I assume your normal approach is of "need to get this out quickly!", and it'll
probably take two months, but so what? Eventually you'll get faster as enough
experiences have taught you what goes well and what doesn't, but you need to
slow down to get those experiences first.

Of course, some people are just super-geniuses. Measuring yourself against
them is just a recipe for depression. To quote 'Eliezer:

"...if you have difficulty with any programming concept, you must not be a
supergenius. You're just an ordinary genius at best. The sad truth is that
there are some people for whom programming comes as naturally as thinking,
with code formed as easily as thoughts; and if it takes an effort to
understand any aspect of programming, you have just learned that you are not
one of those people. Alas."

~~~
superquest
+1 to work with other people. Sounds like OP hasn't done much of that yet ...

------
codr4life
Write more code. Learn different languages. Reinvent wheels. Stop following
the herd. Most of the people who's code you're admiring have been blazing
their own trails for decades. There are no short cuts to experience. Good
luck!

~~~
sitkack
This is not the answer. Write code with careful attention. The OP has written
at least 30kloc, this is more than enough.

~~~
codr4life
I don't agree, lines of code has nothing to do with experience level. Hitting
your head against the wall trying to solve new kinds of problems is where the
gold is. And that takes time, and courage.

~~~
sitkack
We agree generally. The OP doesn't need to code more, they need to think more
deeply, with more purpose. They probably should actually write less code.

~~~
Ronin354
This definitely sounds right. But is this from your experience ?

~~~
sitkack
It is from experience. When I was a junior programmer, I overly focused on the
end goal, coding until "things worked". Projects got finished, but the
internals had cruft and parts were poorly understood. I was not mastering
anything. Now I do more thinking, parts that are poorly understood are mapped
out with unit and integration tests. Those tests are just little scientific
confirmations of how universe of the application works.

------
seanwilson
> Over the past 3 years, I've released a few apps on iOS: not bad, nothing
> that would amaze anyone here. The code is generally messy and horrible, rife
> with race conditions and barely holding together in parts. (Biggest: 30k
> LOC.) While I'm proud of my work — especially design-wise — I feel most of
> my time was spent on battling stupid bugs. I haven't gained any specialist
> knowledge — just bloggable API experience. There's nothing I could write a
> book about.

Why do you feel you're doing anything wrong..? If you've released multiple
apps (30K LOC is a lot!) you're way ahead of most people who never release
anything. Comparing yourself to the most prolific developers is a recipe to
make you feel bad about yourself.

Writing 30K LOC with minimal bugs is a massive undertaking by the way. Maybe
look into using languages with stronger type systems along with automated
tests to help. Also, you could rely on third party libraries to do more of the
heavy lifting or just remove/simplify features you don't really need. Either
way it just takes a lot of work and time.

------
itamarst
It sounds like you're working alone? Getting feedback is key to learning, and
it's hard to do that on your own.

1\. If you have skilled coworkers doing code reviews (or contribute to an open
source project that does code reviews) you will get a lot more feedback.

2\. Writing unit tests will provide some level of feedback, but it's not as
good for learning as human feedback.

------
JamesBarney
Learn how to write. This is something I'm working on slowly. But seriously,
documentation can separate successful open source projects from unsuccessful
ones.

Also when you're working for a client ability to communicate and make sure
you're building the right thing will trump building the thing right.

------
heisenbit
There are several aspects I see

\- Writing 30KLOC yourself is a real lot

\- Maybe it is too much? Try at times to refactor to make it denser

\- Good libraries come from re-use. Either a genius came up with something
reusable from scratch or someone got better at solving a problem until a piece
emerged that was worth sharing.

\- Good libraries come from discussion and exchange of ideas. There is a lead
but there are contributors too.

\- There is a difference between apps and frameworks. The code and not the app
is the product and customers are devs. Has implications e.g. how to do
marketing.

\- Are you made for this? Some solve problems really fast and good enough,
then move on. Some others solve problems really well and stick with problems
for a long time. Both types have value. Look at your life outside coding for
clues.

------
codecamper
First off, you can spend a lot of time adding amazing features that are never
used.

Second, many successful products weren't all that complex. (though I'm not
sure if these days still exist)

Third, realize that most stuff that gets created disappears into the infinity
of time & just gets replaced with other stuff.

Fourth... do you love your grandparents? (or parents, or friends) I hope you
still have them. If so, then be sure you call them on their birthdays & on
holidays. Maybe even send a card. Spend as much time with them as possible.
They are truly the most important things to your life. The rest is just icing.

------
analog31
Maybe you need to get yourself into an environment where there are other
people around who can critique your work, and from whom you can learn better
habits through observation. This may work better in an environment where you
are in physical proximity with co-workers, i.e., a traditional software shop
kind of job. Even if this kind of work isn't your ultimate dream.

Also, maybe some people are better suited to solo work, and others to group
work where there is some rigor imposed by the team or by the employer. You may
be in the latter camp.

------
gaelow
Coding ability wise, elite coders are usually already well above the average
professional senior programmer level while still in their teens (emphasis on
coding ability wise).

But,

\- They are a tiny fraction of the collective. Pretty much everyone else sucks
at programming.

\- Coding is like working out. Even if you are not elite, you can improve a
lot if you persevere. All the way through your entire career, no matter how
long.

\- It is not all about coding skills. Maybe for those 40k LOC one-man app guys
it is, but that's not even the most common scenario anymore. You can
compensate with other skills such as being inspirational, having good
insights, ability to QA a product/design and identify its weak spots and
potential on the early stages, ability to break down a problem into smaller
ones and prioritize your tasks, ability to evaluate, understand and
communicate with team mates and clients (social skills with coding skills is
always a winning combination)... The list goes on and on. Even though it's not
all related to programming, it is stuff you'll eventually have to deal with as
a professional programmer, specially in the startup world.

Code is reusable. You don't have to be a genius coder to put together a slick
and successful app. Even for the most innovative software, the code of every
part is most likely already there, written by experts in a clean, efficient,
robust and well-documented module you can use free of charge, even
commercially. So go on and use it. (I know it's actually not that easy, but
mostly piles of crap until you find something useful and learn to use it
properly. You get better at that too).

------
blablabla123
It's all a matter of perspective but if you want to work on it, these things
can be learned.

Around 5-7 years ago I didn't consider my code exactly high quality,
especially when building things from scratch. So I tried to understand what
makes good code good, and actually how to spot it. Mostly through reading blog
articles, reading actual code and thinking about code. I also got books but
only 5 in these years in total. I read only 2 of them through.

So Google is your friend... Have problems with race conditions? There are
solutions to that CSP (Golang), Reactor pattern, using 0mq or even STM.

Also don't forget that one things is skill/experience, the other is choosing
proper tools. Are you using a simple editor or a heavy-weight IDE? When trying
MIDI over Wifi do you Google and try to reproduce the first blog entry you
find about. Or do you rather choose high quality components/libraries? #
Github stars are a nice indicator for good libs with concise APIs.

But yeah, on the other hand you also need to ask yourself is it worth it? Do
you want to be mega focussed and productive? Or do you want to create various
things? Being super productive in some place sometimes feels for me a bit Zen-
like but on the other hand also a bit boring.

------
SixSigma
Lots of programmers like me, started when they were kids - I was 11 when I
started writing code. 36 years later I'm still learning and I don't mean
"learning to use such and such API".

I've hung around awesome programmers too, much better than I. Some you will
even have heard of.

Specialists knowledge didn't just fall out of the sky. It takes research &
patience.

Some people will always be better than you.

Your focus should be on being better than you were yesterday.

------
codetoon
It is important to realize our current situation before we can upgrade
yourself, so it is good you know that and are willing to do that.

Personally I believe that everyone has some natural strengths in one domain or
another, that gives them an edge to do things a lot faster and can learn and
understand things lot faster. For example I can understand technical stuff lot
better and can learn new programming stuff lot faster, than I could ever learn
playing a guitar or designing :) I believe that the people you mentioned above
are excellent programmers/architects and beyond that they have seen and dealt
with more situations than any one doing regular programming. They might have
built complex stuffs, they have read a lot - books and open source code,
cleared the concepts, they have grown their knowledge and they have
implemented it where they could. Basically your programming skills improve by
doing complex stuff. Applying what you have learn't whenever you get a chance
(no matter how simple or complex the product could be). Implementing elegant
solutions to problems that can have N possible solutions and no compromises.

I don't say that being a programmer I cannot become a good musician but I
think that the music I produce won't match the quality of the code or program
that I would write, and even if I could do it - it requires a great deal of
effort time and dedication which I wouldn't have required at that scale for
coding. I am a programmer first and then may be a musician second. Someone
would realize their own strength and work to polish it further, or may be
someone would choose to become someone that interests them but it is not their
core strength. It's a personal choice.

My comment might be felt negative but I wrote this because I see a burning
desire in you to do something and you have been trying it past 3 years, It
might be worth to stop and point you to other perspective instead of giving
you any standard advice. However if you are determined to take your level up
than no one can stop you - all you would require is to rewire your brain - a
great deal of effort and strong dedication. Personally I found books and
reading open source code to be a good source of improving your programming
knowledge and like any art I think the more you do it the better you become.
You may also find some job/freelance in some decent company where there could
be challenging work/projects - that can help you grow your knowledge rapidly.

------
blt
There is lots of good advice in this thread. I would like to focus on your
comment about race conditions. It's very good that you have identified this
weakness in your code. Writing concurrent code is hard, but it's also valuable
experience because there is no room for shortcuts. If you don't do it right,
your code _will_ fail eventually. Therefore writing concurrent code,
identifying bugs, and fixing them will train you to think rigorously about
your code.

Diagnosing bugs often comes down an exploration of every possible sequence of
events, trying to identify the pattern of sequences that triggers the bug, and
figuring out how to fix it. In single-threaded code the debugger can make this
task easy, but attaching a debugger (or even building in debug mode) often
makes concurrency bugs go away, so you are forced to solve the problem in your
head by analyzing the system. This experience is like strength training for
programmers. I would suggest putting extra effort in the concurrent parts of
your code, really try to make them correct. In the end, the practice will
improve the quality of your non-concurrent code too.

------
20andup
Judging from what you said. You need to learn to read the language rather than
simply understanding the syntax. You need to understand what is going on under
the hood.

Programming languages are just a bunch of random symbols and letters; each
language has different syntax. But underlying them all is the same foundation
of how languages are created. Learn to read your code like an essay rather
than simply focusing on the sentence.

------
faitswulff
Well, you could start with similar previous posts:

[https://hn.algolia.com/?query=better%20programmer](https://hn.algolia.com/?query=better%20programmer)

I'm particularly interested in this thread, "Ask HN: What habits made you a
better programmer?":

[https://news.ycombinator.com/item?id=1674103](https://news.ycombinator.com/item?id=1674103)

------
shakkhar
A bit late to the party, but I will chime in.

\- Every developer out there at some point in his / her life felt the same way
as you do. Likely more than once.

\- There aren't many developer who can look at their own code written 5 years
ago and be proud of it; may be if you are John Karmack.

\- Being able to write beautiful code is definitely valuable, but being able
to make a product is even more valuable.

\- The programmers you mentioned are kind of by definition exceptional.
Otherwise they wouldn't get your attention.

You are not missing anything. You are just like the remaining 99% of us. And
it looks like you are already trying to get better - so you WILL get better.
Every piece of code you read, every book you read, every time you get a code
review - you will improve a little.

Sadly, there is no formula to turn an average person into a prodigy. So don't
beat yourself up.

------
deepaksurti
>> Major features were added over the course of weeks! >> — to say nothing of
getting the overall architecture right from the start.

[Most likely] it is not that they got it right, right from the start. These
'awesome' programmers would have spent weeks before getting it right. These
classify as throw away experiments and they keep at it till it satisfies their
own internal target of what the solution should be like till it is right.

The best parameter of that right could be say the simplicity of the overall
internal implementation and the exposed external API.

Now I am not saying that there are not geniuses around, but even if they are
getting it right, it will still be backed by countless hours of hard work and
practice.

Most likely asking these awesome programmers how they are getting it right,
will throw some more light.

------
bitwize
There are no shortcuts to "supercharging" your work. Git gud, bro. Put in the
effort. When you see exemplary code, study the principles behind it and seek
to emulate it. I'm a better C programmer now than I was, for instance, because
I read a lot of BSD source.

------
partycoder
Some time ago I worked porting software. The software we ported was very
successful financially. It also looked very polished from a user perspective.

But when I read the code I saw the code was really suboptimal (tech debt, and
sometimes more convoluted than it strictly needed to be). That changed my
perspective on code a bit. That did not change my programming rigor though.

My point is that sometimes excellent products are not necessarily excellent
from an engineering perspective.

Now, to assess your engineering skills there's a book called the IEEE SWEBOK
(Software engineering body of knowledge), that is an index of the different
areas of software engineering. You can go through each one and assess your
strength and work on some of the imbalances this assessment would reveal.

------
spotman
The fact your even asking this means your ahead of a lot of your peers.

None of this comes overnight. Many of us start out incredibly messy, and there
is nothing wrong with that.

In fact it might give you an edge over folks that start out very elegant and
by-the-book because you are used to dealing with things like race conditions
and they expect none.

Remember this, the best code is never written the best it can be the first
time around, and in a lot of cases never.

Code is a moving target, stay light on you feet, avoid religion of certain
methodology ( to an extent ) and paddle towards things that you are proud of.

You will be fine and likely do great if you stick with it.

Finally, there will always, always be someone who knows more to you. There is
no end to what you don't know. The sooner you make peace with this the better!

------
ared38
If you want to become a domain expert, become a domain expert. You won't learn
the intricacies of the newest structure from motion algorithms by writing
user-facing apps. you have to specialize, possibly for years, until the domain
is second nature and the code is just putting your knowledge into text, if you
want to singlehandedly write a world-class library.

But for heavens sake, why? Do you actually care about how audio destuttering
works, or do you just want your app to work well? Do you want to spend every
waking moment thinking about a problem, or take time out to deconstruct Marvel
tropes?

And yes, the programmers your talking about are the 1%. Do you think every
good dev has books written about their work?

~~~
tastyface
I don't care about audio destuttering, but there will come a time when my apps
will be made better by a finicky feature that requires similar expertise.
Rather than dreading the process (as I do now), I want to learn how to
efficiently source this kind of domain knowledge and then implement it without
too much of a hassle. Deep, needle-precision learning.

Most programmers don't have books written about their work, but I think most
great programmers (of the kind I admire) _could_ write an in-depth book about
the unique things that they've written and discovered.

------
harigov
You should do some data analysis on where you are spending most of your time
when building software and see if there is a way to do it faster. You can read
books and follow someone's advice but nothing can be more useful to yourself
than trying to navigate your own mind space in search of answers that you are
looking for. If you figure out that you are spending most of your time
deliberating how to name variables, you should spend time reading about
programming styles. If you spend time debugging, identify what sort of bugs
you are creating and try to go over books that cover most common programming
bugs and try to incorporate them during programming time itself.

------
rjblackman
read clean code [https://www.amazon.com/Clean-Code-Handbook-Software-
Craftsma...](https://www.amazon.com/Clean-Code-Handbook-Software-
Craftsmanship/dp/0132350882?_encoding=UTF8&redirect=true)

and clean coder
[https://www.amazon.com/exec/obidos/ASIN/0137081073/metafilte...](https://www.amazon.com/exec/obidos/ASIN/0137081073/metafilter-20/ref=nosim/)

If you follow the (admittedly pretty extreme) advice in these books you will
be in the top 10% at least.

------
lmm
The secret is to use good libraries and especially good languages. That you
were chasing race conditions at all implies that you were programming at far
too low a level (unless you really did need some super-tuned thing, which it
sounds like you didn't).

I'll guess that you're self-taught, and learnt one of these low-level
languages that makes you spend most of your time dealing with irrelevant
concerns? I'd recommend going back to basics, learning ML or a similar
functional language, and rediscover how to program from the ground up but
doing it right this time.

------
hyperpallium
Actually typing code doesn't take much time. Understanding the problem is the
difficult bit.

If these developers are already familar with an area (perhaps even implemented
it once or twice before), they can do it very quickly. Or have an
office/community of people who have, or seen other solutions, or are good at
researching/asking online (eg Larry Page asking for help with his java spider;
you now).

Consider: how long would it take you to add cut-and-paste to your next app?

Race conditions are a nightmare for just about everyone. Change your
architecture to minimize cross-thread communication, and use queues when you
can't avoid it.

APIs also can be a nightmare, difficult to understand, don't do what you need,
under-documented and of course have their own bugs and required workarounds.

Finally, if you're still spending too much time debugging, you might need to
change your approach in other ways. e.g. code only a bit at a time, testing it
immediately, so you know what has introduced the bug; write modules that you
understand, so once they are debugged, you don't have to worry about them;
unit tests can help but aren't essential. It can be helpful to trace through
their source code, so you know what's happening.

If you understand what you're doing, bugs are usually easy to diagnose and
fix. It's gaining the understanding that takes the time - and, I would claim,
_is_ programming.

Maybe there are programmers who, due to prior experience, concentration
powers, talent, memory or raw intelligence, _are_ ten times faster than you
(or more!). That shouldn't discourage you from creating something worthwhile.
Time spent doesn't alter its worth. Provided it doesn't take _too_ long to
complete, does this pride in competitive efficiency really matter?

BTW: Worth, popularity and usefulness are functions of the problem solved -
not of the solution. A polished solution to a problem no one cares about has
doesn't help anyone nor get much attention.

Whereas an ugly solution to a huge problem will change the world. Even
mathematicians and theoretical physicists sometimes start with inelegant
solutions, though they get polished over time.

------
LiweiZ
I'll be 35 next year and started writing code when I was 30. I have very
similar experience. This year, I focused on how to write better code instead
of designing and building. I'm slowly getting better this year. My biggest
code base for one of my prototype was around 25k LOC. I mainly wrote iOS app,
too. I spent more than one year to take care of my kids so there was a long
gap. And it has been difficult for me to find a job. There are always
meaningful ideas and having the ability to bring some of them to life is my
biggest motivation.

------
hellofunk
> The code is generally messy and horrible, rife with race conditions and
> barely holding together in parts.

It's very good that you've had the experience of writing bad code, and
recognizing that. It will make you expect more from yourself next time. And
the process repeats. After many iterations you will be much better. And also
more nimble. Writing 1000 lines is a lot for someone who has never done that
before, but natural for someone who has a million lines under their belt.

------
zznneezznnee
Before you compare your work to that of others you really need to know how
much time was spent on both and normalize accordingly.

Additionally, many individuals in our industry have zero life outside of
hacking on their software. It's difficult if not impossible to be competitive
with someone spending every waking hour practicing their craft without doing
the same.

------
pmyjavec
Don't worry about it, enjoy your life, spend time in nature and cook yourself
some nice food for dinner :)

~~~
symlinkk
I doubt you intended it this way but the little smiley face comes across as
being super condescending :)

~~~
pmyjavec
I was generally trying to add some friendliness to my suggestion!

------
mcheshier
Don't be too hard on yourself.

If you're looking at other people's code and finding new insights you can
apply to your own work, you're doing it right.

When you look at your old code and wonder:

How did this ever work? What idiot wrote _this_? WTF was I thinking?!?

You're doing it right. It's a sign of growth and improvement.

------
satyajeet23
Reminds me of Developaralysis ([https://techcrunch.com/2014/10/18/you-too-may-
be-a-victim-of...](https://techcrunch.com/2014/10/18/you-too-may-be-a-victim-
of-developaralysis/))

------
marmaduke
I think the first few years of programming are the most difficult. You have to
go through this process of building and throwing away. Only with that
experience you learn to anticipate things should be put together. That makes
thing go more quickly.

------
boon
At least when you talk about reviewing code that "someone wrote in a month",
note that a quick `rm -rf .git; git init; git add *; git commit` works wonders
for others' perception of how quickly you can produce code. :)

------
olalonde
Having spent an embarrassingly large amount of time working on small libraries
or side projects, I'd say you are probably underestimating the amount of time
that was spent on those frameworks.

------
syngrog66
this rings as very fake and/or blatantly self-promotional. I wish HN had less
of this type of post. I feel like a certain percentage of HN posters have
learned how to push enough of the buttons of the rest of you to make it a net
win for them. just nauseating.

And now come the downvotes, because I know I am effectively "not allowed" to
express this kind of opinion without penalty -- yet I don't care, let's burn
it up.

~~~
tastyface
Self-promotional for what? I have no affiliation with any of the frameworks or
apps I mentioned, and I'm getting exactly the kind of advice I was hoping for.

~~~
lawik
I can understand someone thinking that this is a bait of some sort. I don't
think it is a bait but it is sometimes hard to separate things that mirror
common sentiments and feelings and things that are written to appeal to the
stereotype around that common sentiment.

I think most developers feel crap about their own creations and I think all
creatives struggle when comparing themselves to their role models. There is
always a more skilled fish I guess :)

------
kornakiewicz
If you compare yourself with others, you may become vain or bitter, for always
there will be greater and lesser persons than yourself.

------
cammil
Do you think you might have a confidence problem? Does this feeling or thought
occur much in other aspects of your life?

------
socmag
Hi

I just realized, I'm pretty sure I'm just passing my 40th anniversary of
programming this month. Jeez I feel old.

How I made it this far I have no idea, but here I am still plugging away.

My eyes are going, I get tired easily, and my productivity is a hundredth of
what it once was...

I look around here and don't know what half of the posts are even about most
of the time :-) In supposed to keep up with recurrent neural networks, the
language of the month, algorithms research, which HTML template framework is
or is not in vogue, whatever...

Over the years I've written a couple of books, built some pretty cool shit and
had the pleasure to work with some of the best, but you know I'm really pretty
damn dumb, and the only thing that has saved me is persistence.

I've felt like you many many times on occasion over the years.

Computer Science is a huge subject, and growing by the day, immeasurably
larger than when I started. There is no way to keep up in all avenues... and
that is fine.

It's pretty normal and healthy to have a bit of a low self esteem about our
work as software engineers because it is literally true that every piece of
work can be better. Please try not to take that attitude a bit too far though.

You know, I got into this because when I was a kid I wanted to understand how
computers work. They were a magical box of wires to me and still are.

I wrote code for fun, my own personal pleasure, and the hope that along the
way maybe some of it is of some use to someone else. Maybe even make them
smile. That's what drives me and keeps me going.

I think my advice is just program because you enjoy it. Everything else will
come.

Financial reward is a side effect, not a cause.

There is no huge race here. Programming is a very personal creative past time
that takes an incredible amount of effort for all of us and a lot of patience.

I know it might seem at times looking around hacker news that everyone is way
ahead. I can understand that, it's a pretty elite set out here. But... I think
deep down, the dirty little secret is everyone feels a bit crap compared to
everyone else on here more often than we all let on. Fake it 'til you make it.
;)

Like others said, you have so much to be proud of. Shipping multiple projects
on iOS, wow!

The fact you are even looking into audio algorithms and things like MIDI over
WiFi is great! Sounds like a lot of specialist knowledge you are building
there. I'm impressed!

Maybe one pointer. Step back and stop, take some time and think about the
machine instead of the problem at hand. I say that because you mention race
conditions. Understanding why they are occurring will be of enormous help.
Then when you figure it out, explain it to someone else.

But meh, stop whinning, It takes me weeks to do what I could once do in an
afternoon :)

You are doing great.

Keep it up man, it's a really fun road.

Nice you are here.. let it flow.

------
jedanbik
Do you need a mentor? What kind of teams do you work on?

------
auspex
You probably should learn design patterns

------
known
"You are a product of your environment." \--Clement Stone

------
buzzybee
Programming is a practice that can be kind of deceptive in its valuation. To
analogize to weightlifting, one of my favorite things to analogize against,
you can see that someone lifted a lot, and you see that they did in fact lift
it all by themselves, but you don't see how they get to that point, and you
can't simply put on the same number of plates on the bar and hope to succeed.

A likewise naive path is to copy example code, do something slightly different
from it, and then wonder why it's broken. You can't be really great at
programming by doing that, because you're abdicating so much control to
wishful thinking: "I hope this example author considered my use case!"

What you can do - and you probably have the guts to do it, if you're writing
30 KLOC apps on your own time - is to attack things one technique at a time,
and to attack the hardest, most lasting stuff first before you get into more
specialized and ephemeral knowledge like API calls. It's the adjustment of
what you care about that leads you to direct your coding towards unfamiliar
yet profitable roads, where you have to envision very big ideas that aren't in
place yet, struggle with them for days or weeks, and ultimately find a great
technique that you can reuse in the future.

To take one example, UI code is wonderful stuff for adding end-user value. But
if you want extreme leverage in your code it can't be the first priority,
because it's also stuff that tends to be thrown out frequently - because other
features change, or you're on a new toolkit, or you found a slicker design.
You have to instead allow the UI to be too crude at first, and think about
application features as a layer apart from the UI. And then only as you come
towards the end, confident that the core features are correct and will be
robust against a partially-working UI, can you go back and invest in a great
presentation.

Likewise, it's tempting to make code that is clever in-the-small, at the
moment you first dip into making a new feature; to invent class hierarchies
and configuration objects and generics and other nifty things. But what you
need most at that moment where it's new is the most boring, plain code
possible, because if you don't know the problem space yet, anything clever
that might add structure or allude to generalizing the problem along any one
axis is likely to do so wrongly, and the most flexible you can be is to assume
it's all disposable and should be extended with copy-paste-modify. Fancy
language features were made to break through problems with the crude
techniques, so if you follow with that grain and only add the features after
you feel pain, everything tends to go much more smoothly.

Most of all, it's scary to take on seemingly big problems, but it's scary in a
way that should not influence your decision whether or not to attack them.
These problems feel big mostly because they aren't well understood to _you_.
In the same way that math students are prompted to take on gradually more
ambitious levels of abstraction, you have to do the same with your code. You
start with your bad assumptions and knock them out with a dash of computer
science knowledge, and a lot more trial and error. There will be bugs and bad
decisions along the way, but you can also learn defensive techniques against
them. Some attempts to defend your code may just make it harder to write or
more brittle; others will succeed dramatically. You won't know these things
until you try(or get very good advice from someone who solved a similar
problem to yours) because every problem domain in programming has a unique
solution profile, where some things matter more than others.

~~~
pacnw
> To take one example, UI code is wonderful stuff for adding end-user value.
> But if you want extreme leverage in your code it can't be the first
> priority, because it's also stuff that tends to be thrown out frequently -
> because other features change, or you're on a new toolkit, or you found a
> slicker design. You have to instead allow the UI to be too crude at first,
> and think about application features as a layer apart from the UI. And then
> only as you come towards the end, confident that the core features are
> correct and will be robust against a partially-working UI, can you go back
> and invest in a great presentation.

This bears repeating a hundred times over. All the more pertinent today when
there is an endless stream of shiny web UI frameworks that constantly tempt
all but the most disciplined and hardy devs.

------
reality_czech
Two words: Ballmer Peak.

------
InfiniteStyles
practice.

------
sean_patel
> Over the past 3 years, I've released a few apps on iOS.

Wow. That alone puts you in the Top 1 to 5% of your peers. Even many
experienced programmers have trouble shipping code. They (we) wait for it to
be "Perfect". The code ends up languishing in some repo and never sees the
light of the day.

1-man frameworks are the wrong things to look at. Don't compare yourself with
them. Of course you'll feel bad and inadequate.

Maybe you need to shore up your self-esteem. I say this because your feelings
about your own abilities will show through in job interviews, and when having
discussions with your peers, and you will get short changed (salary,
promotions etc).

So I would say, just keep at it, and try to improve everyday. And don't
compete with others, compete with yourself.

------
gragas
>the code is generally messy and horrible, rife with race conditions and
barely holding together in parts.

immediately followed by

>I'm proud of my work — especially design-wise

ummmmm.... what?

~~~
dllthomas
I assume proud of completion, and proud of UI design.

~~~
gragas
Ah, proud of UI design makes sense. I thought OP was feeling proud about
his/her program design, immediately after mentioning it's so awful.

~~~
dllthomas
Yeah, that wouldn't have made a lot of sense :-P

