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.

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.

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.

To put it more succinctly: there will always be someone better you.

But there's a good side that - if there's someone better than you that means you have someone to learn from. So when you encounter good code take the time to learn from it (and from the mistakes its authors made when they were less experienced: https://codewithoutrules.com/2016/03/22/language-evolution/).

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

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.

So true. It took me 10 years to master my skills. Am I perfect? I still question my skills on a frequent basis. Here is what I can confirm - it gets easier over time.

I can take on any small, large, extremely large and complex projects head on and amaze myself at the end.

The most difficult thing - being disciplined.

I will always admire someone else's code. I find it inspiring. I have on my bookshelf "Beautiful Code".

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... ). 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.

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.

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.

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.

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.

> 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.

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.

I'm > 40 and have a very similar story. I mostly work alone now , have never written a unit test in my life and have a few very large mission critical apps with many millions of dollars of revenue ti d to them. Mobile, native desktop and web. I take my time and thoroughly think through a change and the implications to the systems. I only try to build reusable code if I'm on my 3rd time of trying to use it. Not trying to build a perfect piece of engineering easily cuts my development time in half

I'm not sure where all this process came from, but it sure does cost the business a ton of money without much return. I would theorize it could be an attempt to abstract the developer from the business process so the business isn't so beholden to one or a handful of people.

On a side note, I embrace source control. It allows me to run down a rabbit hole and not worry about having to get myself out of it.

To the OP: Look at popular code bases and see how they are organized. Run your debugger through them and see how they work. Organization is the key to maintainability. DRY (Don't repeat yourself) and KISS (Keep it simple, stupid) are your friend. Like anything, the more you do, the better you will become.

I think you are that person who knows the rules so well, he can choose to break them at will.

So the quality is reliant upon your 'personal software process' or individual discipline while you work rather than upon practices like test-driven development, continuous integration, etc.?

I work in an environment like this. The need for TDD and CI are greatly reduced through the use of modular code design, encapsulating major logic/system units with a uniform API, and coding standards. The emphasis is inherent program quality as opposed to external quality checks. One consequence is the discouragement of individual creative flourish: "clever" code is discouraged, and descriptiveness is favored over terseness. This makes the code easy to understand, to modify, to check for correctness, and to reason about. Of course, there are still unit tests and integration tests, but their role is more low level and less visible.

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

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.

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.)

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.

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

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.

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

It does really bother me that we've created a culture centered around Cracking the Code Interview and cramming for interviews.

agreed, we should thank google for that (or not) :)

It didn't start with Google. Microsoft was doing much the same thing back in the nineties.

Thank you for formalising into words what I have felt for quite some time. This comment resonates with my core beliefs. Virtual high five!

Not to forget another gem from the same book that I ardently recall when it comes to self-doubt.

> Don't make the mistake of underestimating yourself.

> I'm not suggesting that you'll go out and write Rails in 3 weekends. What I am suggesting is that the more I meet "famous" hackers and the more I meet people from this community (online and offline), the more I realize that there's not really all that much that separates us.

> Lot's of people are obviously brilliant. And even for those who are a little less brilliant, brilliance is only one part of the equation. Work habits, determination, perseverence, passion, and maybe most of all, belief, are just as important. Don't sell yourself short.

Related to the idea of pull, I've found that learning from mistakes is in some way the only real way to learn. Like I'm trying to learn about furniture making for practical necessity reasons and it's so clear that the only real way to understand is to make something and then see why it doesn't work and then make something better.

Hey, for those of you who are leaning towards the "push" style, what helped me most when learning something new "by the book" is then to try to teach it to somebody :-)

I am a regular employee with fairly well defined role in the team, which means that new problems to crack an learn from don't come that often.

On the other hand, we have knowledge-shares, lunch-n-learns, tech-talks, lightning-talks and even cooperate with local universities to teach some course-work :-)

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.

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.

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.

>>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.

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

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

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.

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.

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.

I'm not extremely experienced, but it's hard not to agree here. I work with neural networks primarily, but I've had to start learning working with JS for interactive visualization. In short, compared to neural networks, it's a giant nightmare.

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.

This is probably the most clear example of that:

http://www.try-alf.org/blog/2013-10-21-relations-as-first-cl...

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

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 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.

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.

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

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

- http://sijinjoseph.com/programmer-competency-matrix/

- https://competency-checklist.appspot.com/

- https://github.com/hltbra/programmer-competency-checklist

... from: https://wrdrd.com/docs/consulting/software-development#compu... )

> 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/

- TDD.

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.

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.

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.

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

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

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

See Norvig's Teach Yourself Programming in Ten Years: 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.

> 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...

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.

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."

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

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!

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

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.

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.

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

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.

Exactly. More time in the saddle. Fix your race conditions (just an easy one from the OP's post) and you'll learn more and next time it will be easier.

> 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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

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.

Well, you could start with similar previous posts:

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

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.

>> 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.

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.

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.

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!

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?

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.

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.

read clean code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

and clean coder https://www.amazon.com/exec/obidos/ASIN/0137081073/metafilte...

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

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.

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.

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.

> 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.

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.

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

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

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

Don't forget naps!

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.

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

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.

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. :)

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.

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.

Well, that's one opinion--unique, judging by the other responses. Someone asking for help and insight is "fake", "self-promotional", "nauseating" and manipulative? And downvotes on such a judgement are somehow out of bounds?

Dude. Take a pill. Get over yourself.

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.

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 :)

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

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

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.

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

You probably should learn design patterns

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.

> 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.

practice.

> 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.

>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?

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

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.

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