Ask HN: Maybe I kind of suck as a programmer – how do I supercharge my work?

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

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

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

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.

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.

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.

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!

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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

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

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

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.

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

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.

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.