Ask HN: How do you keep improving?

[Superleroy]

I am currently in my ~8 year as a developer, doing my Masters degree while working as a part time developer. That said i find it quite hard to keep improving, i know a lot of people that are better than me but i seem to be unable to really learn from them. What i found out is that i rarely take the time to lern something in depth because i mostly learn stuff to use it and tutorials seem to move at a way to slow pace, so i mostly skip them.

As an axample, i started out with C/C++ development but am unable to keep up with the new standards. I see people write really nice code but whenever i sit down i just keep reusing what i know. The same goes for architecture, i have been building stuff for a long time but other people (with not that much experience) tend to be way better at abstracting stuff or architectual design than i am.

How do you guys keep lerning new stuff? Any techniques or tips?

[itamarst]

1. You need to recognize when you're not learning, for one thing. If it's easy, you're not learning. You need to push yourself into the zone of discomfort, where you feel clumsy and have a hard time. Now you're learning.

2. Find a mentor. Lacking that, find e.g. talk of someone explaining some hard techniques and then try to follow the advice. Even and especially if it feels clumsy at first.

(More on those two here: https://codewithoutrules.com/2017/04/17/learning-without-a-m...).

3. Switch to a new job where you'll be exposed to new things. try to find a job where people do code review, feedback is how we learn faster.

4. Learn how to learn: https://www.youtube.com/watch?v=FKTxC9pl-WM

5. Reflect on your mistakes, try to find what cues you missed and what you should look for next time. I've been doing this on weekly basis (you can read the results at https://softwareclown.com) and I've learned a huge amount from figuring out underlying cause of what I did wrong.

[Afforess]

I agree with everything you said. What needs to be feared is complacency. If you ever feel that things are going too easily - that's when to be afraid.

I will be the first to admit I let many _months_ of complacency pass me by before I identified the signs. All the above advice - forcing yourself into the haze of discomfort, breaks this away and forces you to learn new skills. Learning is often glamorized, but in reality, the actual _learning_ phase is painful and uncomfortably hard. I still don't enjoy it, even though afterword, I appreciate the knowledge and extra skills. Instead, it's important to build habits that lead to continuous learning, rather than one-off improvements. Paradoxically, it's easier to become normalized to regular discomfort than rare, unusual discomfort. It has never stopped being uncomfortable to learn for me, but I also have built it my psyche.

[garysieling]

If you have time, side projects for research can be a really helpful venue. In a work environment, there are always areas of the product/business you don't work on, and having your own project forces you to learn how the entire process works - I'm thinking of software - so things like web app deployment, design, taking credit cards, etc are often done by different teams.

A project that is visible gives you material for talks at meetups/conferences or articles for bigger blogs, which is a good way to meet people and get better at soft skills.

For people who have a experience / existing knowledge, watching conference talks can be a good way to add on new knowledge (e.g. my machine learning knowledge from school is getting dated, but seeing new tools / techniques in a talk is enough to figure out what to research).

Here's a big list of conference talks that I've been working on as a project - http://findlectures.com/?p=1&class1=Technology

[KerryJones]

One of my favorite quotes "I never got that comfortable being comfortable."

[ziikutv]

Number two is very important. A good place to find some informal mentorship is in irc chats.

Shout out to Aria from #node.js. What an amazing developer. The best example of a self taught/homeschooled success story. Aria taught me a lot of stuff related to Node and is also active on the channel.

[steveeq1]

Upvoted for "Learn how to learn", awesome talk.

[Joeri]

Teach. Find people to mentor, find user groups to present to. There is no better way to learn more about subjects you're superficially familiar with than to teach them. Pick subjects where you think you're an expert, and prove to yourself that you weren't, or pick subjects that you would like to know more about and try to understand them well enough to explain to someone in 45 minutes.

You will be terrible at this at first, but teaching is also a skill that takes lots of practice to acquire.

I would also agree with what others said: stop comparing yourself to others, no good will come of it. There is always someone better, there is always someone worse. It doesn't matter. Set a standard for yourself and meet your own standard.

P.S. If you're looking for a good resource to learn presenting from, I would recommend macsparky's presentations field guide.

[ghubbard]

If you want to teach without leaving the house or standing in front of a group of people, try http://exercism.io/ (Open Source and free).

Solve simple coding problems, review the submissions of others and help them become better coders. Trying to clearly explain concepts to others is the best way to make sure you really know them yourself.

This is also something that you can do for 10-15 min every day, which will add up over time. Ask for feedback on your own solutions and find out ways others think you could improve things.

[wallflower]

I saved this comment from jlcfly from an AskHN that was answered a long time ago.

"Teach them to be better than you. That may seem counterproductive. I have a type A personality, and I have decent coding skills. I've been in your situation a number of times. I also know there's these mythical expert developers out there that I can't seem to find (or afford). So, what to do? A few years ago I realized that if I continue down this path, I'll end up with some serious health issues due to the stresses that come along with having a reputation for being a really good developer. So, I decided that instead of searching for developers better than me, I would teach developers I work with how to BE better. It's taken a lot of patience. And it's taken me quite a bit to LET GO of my way of doing things. I had to take my ego out of the picture. (VERY hard to do.) Nowadays, I realize that developers don't have to BE better than me. I simply have to ALLOW them to do what they do without being so obsessive about it. Turns out, even junior developers really CAN do good work. They just need a little guidance that only comes with experience, and then they need me to get out of their way."

https://news.ycombinator.com/item?id=8649415

[xealgo]

I for one will often (and usually naturally) befriend the most talented developers I work with. Talking code often and bouncing ideas off of them will really help you see where you're lacking or where you can improve.

Learning new languages and different paradigms can also play a huge role in how you approach future problems. Go to glot.io and play around with a handful of languages you've never touched.

Read up on various best practices and style guides. Read blogs on architecture, design patterns, etc. I read probably 5-10 hacker news articles daily, but I also watch many videos on youtube such as pretty much anything by Martin Fowler, Rob Pike or any of the other greats.

Code stuff outside of your comfort zone. If you're a web developer, try writing some games. If you're a game developer, write a web server or a blazing fast load balancer that handles TCP/UDP sockets and HTTP. I code random shit all of the time just to gain some exposure even if I'm never likely to do related work in the future. I probably have a few dozen Go programs I've developed just because I was curious how something worked.

I've been programming for over 17 years starting with C++ when I was 13. Over the years, I've developed stuff in C/C++, Python, Ruby, Lua, C#, Java, JS, TypeScript, SQL, Dart and Go for the past 3 years. Each language has given me new insights in how to tackle problems that knowing say just C++ alone would not have lead me to.

TLDR: Exposure!!, Books, Blogs and LOTS of bouncing ideas off of other developers.

[markeroon]

I'm not sure that this is the way. It's much easier to get a small amount of knowledge about a lot of topics. If you want to be a generalist then that's great, otherwise, I think it's important to keep asking yourself "How can I drill deeper?"

This is specifically regarding the third point; I agree with the first two!

[qaid]

I agree -- Being curious is a great way to improve yourself. Can you please recommend to me blogs on architecture and design patterns?

[johnfn]

I work on progressively larger and larger apps. This teaches me more and more about coding in the large, in a very practical sense. Every time I learn about something new, my learning is explicitly motivated by the problems that I ran into while implementing the large app.

I started by making a reasonably conplex TODO app, which took a few months. This taught me about the importance of declarative (popularized by React) style programming, and MVC separation.

Then I moved on to building a Vim extension for visual studio code. This took about 6 months, and taught me a bunch about programming larger apps and keeping them bug free. I also learned a lot about open source maintenance. I learned why Redux-style architectures are important.

Then I moved on to working on a fully featured pixel editor. This has been my toughest app of all. I've been working on it for about 4 months full time at this point, and I've learned so much about canvas perf, js perf, the importance of end to end testing, ... I could go on for a very long time. :)

And this is all a warmup for an even larger app I haven't started on...

This approach seems to have worked well for me, and I'd recommend a similar style approach of working your way up from smaller programs to larger apps. You learn lessons from smaller apps that will save you a lot of time when coding larger apps.

[molloy]

Do you mind sharing your vim extension? Would love to check that out. My coworker is interested in learning vim and he uses VS Code, so it sounds like a good introduction.

[andai]

If you don't mind sharing, what's the big app you're warming up for? :)

[beat]

Start by comparing yourself to yourself, not to others. Don't worry about matching others for their strengths. Just be a better you tomorrow than you were yesterday.

Next, distinguish between depth and breadth. Are you a generalist by nature, or a specialist? I'm a total generalist. I've achieved basic competence in a truly shocking variety of different subjects, but the main thing I'm an expert at is being a generalist. I've gotten very good at picking up new skills whenever I'm interested in them.

Other people are specialists. They find something they're passionate about, and they get good at it. Really good. They go deep. They may not know a whole lot of things, but that one thing they know, they know so well it's hard to even comprehend from the outside.

So are you a generalist by nature, or a specialist? Do you want to be one or the other? Pick a direction and start walking.

[sahilkhosla]

Is one better than the other?

[vikingcaffiene]

Dev with 10 years experience here. Self taught.

There are couple ways I keep up on things (keeping in mind that there are no absolutes and everyone is different).

First, I identify subjects that are both interesting to me and have traction with the developer community. Forums like this one are generally a good sniff test. I then subscribe to mailing lists that deal with that tech. I clip a lot of articles and code snippets to a datastore (Evernote in my case) where I can peruse my notes later. I install said tech and build little micro apps and generally futz around and have a good time. The key here is to be interested in the tech you are trying to learn. Maybe you are bored with C/C++? Whats the harm in looking at something totally different like Ruby or NodeJS? They might give you ideas or a different way of looking at things. Whatever it is, try to have fun. Learning doesn't have to be all drudgery.

When I want to take a deep dive (usually after a good bit of research mentioned above) I find a job working with the tech in question. Nothing will force me into gaining a deep deep understanding of a technology or concept like getting thrown into the deep end. After a year or two at that job, I emerge a ninja level dev in that area. Not a bad deal if you ask me. If that approach is too extreme maybe you can just set up a side project or contribute to open source? Anything that forces you to sit in a chair and produce functional code in the manner with which you want to learn is going to accelerate your learning in ways you never thought possible. Good luck!!

[andai]

Interesting to see the range of responses in this thread, eg. you are advocating keeping it fun and interesting, whereas other people recommend deliberately doing things you don't like.

It might have to do with different personality types. For instance, I am prone to procrastinate on anything that doesn't interest/excite me, so when my goal is to work on stuff I don't like, the output approaches zero.

I resonate with the "do more than nothing" approach advocated by Khatzumoto of All Japanese All The Time[0]. Which is a great website by the way!

It's all about how language learning can be fun. It's like 10% language learning advice, 90% "you can do it stop beating yourself up".

[0]: http://alljapaneseallthetime.com/

[huangc10]

I'm currently reading Zero to One by Peter Thiel. Here is one thing interesting he mentions.

To grow, one can either scale vertically or horizontally (paraphrased).

Now if we apply this to your situation , scaling horizontally would be learning new languages, ie. Objective-C, Javascript etc. I'm assuming you're not really about this but you want to scale vertically.

If scaling vertically is the case, then what you really want to focus on is doing something either 1) other people have not done before yet and/or 2) do something that is 10x better than what is already out there. I don't do too much C/C++ dev but maybe think about embedded, OS, GPU, etc.

If you accomplish 1) and/or 2), then you can truly master C/C++ dev. My 2 cents.

[mikekchar]

For me the biggest thing is always to question what I think I know. It's easy to get into a local maxima. You often need to take one step backwards to take 2 steps forwards.

In practical terms that means that you need to change the way you write code. And that means practice. Katas are good, but you have to force yourself to do it differently than you would normally.

Here's an example of something I did recently: https://github.com/ygt-mikekchar/es6-monad-challenge/blob/ma...

This code is clearly insane. You would never do it this way in production. Or would you? In reality, how do you know what the advantages and disadvantages are if you never try it?

But small toys and katas are not enough. Architecture and design requires practicing on a big scale. That means side projects that you have complete control over. It's unfortunate, but this stuff takes time. If you like programming it's not bad, though :-)

Always get ideas from other people. Read books and blogs to get more ideas. Then go nuts. The hardest part is to have to courage to absolutely suck. Picking insane things to do will help with that because you don't have the feeling that it must turn out good in the end. It's insane.

Hope that helps!

[proximacentauri]

For me it's a iterative process of read->apply->get stuck->read->apply.

I focus each morning on working on the number one thing I have to do that day, in the afternoon I can attend to other less important tasks.

Josh Kaufman has some good tips (https://first20hours.com/).

Also as John Sonmez (https://simpleprogrammer.com/) would say - trust the process. Don't focus on immediate results, focus on the process of reaching your end goal

[bsenftner]

I find asking this question to be just slightly misunderstood. I am currently in my 35th year as a developer, and the learning and improving is easy with one simple ingredient: interest. Pursue what interests you, do the research, write your own versions of the latest research, and when stuck contact the authors you're following. You'd be surprised at who responds, and coming from a perspective of interest the response may be more than expected.

I've been doing C/C++ for my entire career, but have also done full web stacks, embedded systems, VFX for feature films, 15 years as a game developer, OS engineer on first PlayStation team, and reaching way back 80's 3D graphics research and Macintosh beta tester and launch developer. All from simply having enthusiasm and a combination of the stupidity to try it myself and then contacting the leaders and asking them what they did about some nit picky point. Next thing, I'm working there.

That type of easy access is only at new technologies. When I was contacting people the digital entertainment industry was yet a dream. EA was maybe 1 year old. I guess my advice is to find something that you find exciting, but is not yet a reality. There are giant industries to be created around software controlled aircraft, everything from IronMan to skytrains, fer christsake. What interests you? Augmented Reality is going to be saturated, but that area is wide open. Hell, everything is interesting. Just be sure to focus. There is success in consistency.

[telebone_man]

How to learn how to learn!

Personally, I used to find it tough to learn things I couldn't immediately apply. That's because I would try and commit them to memory in a way I could immediately retrieve them if required. So spawned a path of memory learning techniques... flash cards... ugh...

Then I was watching a Derren Brown show (a British 'mentalist') who taught a guy to memorise hundreds of books so that on command he could read out the content of any given book, any given page and any given number.

The individual would read the books in a particular way (picture dragging your fingers down in a v shape across the page). When asked to reiterate the content, it was very important that he just trusted his gut. And he got it right every time.

The key takeaway for me was that it's equally important to learn how to retrieve knowledge.

Slight tangent here, I also remember reading about how Steve Jobs was able to 'think outside the box' and come up with seemingly new ideas. And the suggestion was he was just good at retrieving knowledge through a confidence of confidence in himself and a non-pressured environment.

Hope that gives you something to think about!

[jsmeaton]

Find an open source project that interests you, and start helping. Even better if it's a project you use and you're aware of some sore spots. Start small, with documentation issues or easy pickings tasks. This is to get you familiar with the project and contribution processes. Then work your way up.

By familiarizing yourself with a large codebase, you'll start to pick up the patterns in use. Having your code reviewed by project owners is a great way to get others to help you improve.

Some projects and communities are better than others. Some can be hostile or quiet, others can be welcoming and active.

Don't just start by throwing PRs at random projects and hoping someone bites. Managing an open source project is work and initially you want to be causing as little extra work for the maintainers as possible.

[enraged_camel]

In our industry (and in some others, such as medicine) learning never stops. If you stop learning, you will eventually (and in fact rather quickly) become obsolete. My advice would be to set aside a certain amount of time every week (5-10 hours) to play with new technologies. Even if you don't master them, they can still give you valuable insights or teach you new paradigms.

There will always be someone who knows more than you or is more skilled. Don't let that bother you. Instead, use those people as role models.

[theparanoid]

Become a domain expert. Examples: networking (IP6, BGP, ...), GPU (graphics, cuda), distributed computing (k8s).

Few people are actual experts in a domain. It takes years to do.

[rafark]

Read other people's projects. Read books on design, architecture, patterns.

Deeply analyse those reads without ever touching a computer. If I feel the need to write code I usually write it in a paper sheet and analyse it.

[johnfn]

I see this advice often. However I feel like it never seems to work for me. One of the big reasons why is that I feel I don't get a sense of all the incorrect approaches and why they don't work.

In a case where there are N incorrect approaches and 1 correct approach, by reading the code of the 1 correct approach I will get no sense of why the author dismissed the other N approaches. I feel this (understanding trade offs and judging which approach is best) is a crucial aspect of programming that is easy to miss when reviewing the solution that worked.

[JesseAldridge]

I actually wrote a tool that takes a screenshot of my desktop every five seconds: https://github.com/JesseAldridge/screen_recorder

Once in a while I go back and review some of the work I did that day and look for ways to improve.

[inimino]

How do you use this tool? What have you learned from it?

[newnaivedev]

I read a article recently [0], and I think you may like reading it. From my username you can see what I'll post here is really naive. But what works for me is failing. Failing sets a precise goal of where is my limit (be it in knowledge, or something else). So keep trying, keep failing and soon you'll find you keep improving. Other than that, a good mentor would help a lot, don't be afraid of asking questions when you don't understand something or think the person can help you improve.

[0] - http://www.daedtech.com/how-developers-stop-learning-rise-of...

[sridharmanohar]

I have been a developer (primarily Java) for 9yrs now. But I recently started learning PHP and now I am learning Python. I wanted to learn these languages not because I had to but because I wanted to. And the best way to learn, per me is to pickup a book or a website tutorial, go through all of it in one go and then come back and do some mini projects for yourself which will enforce you to apply the concepts that you learnt. It won't be easy in the beginning but I find this a better way to learn any new programming language or any new concept. Because this way you are actually putting your theory into practice and when you are doing so you also have the big picture in mind.

[kodisha]

Many great answers, and many of them encourage people to try new things, and go and try to build new things and try stuff you don't know.

I like somewhat different approach, I would take some project I think its done well, and where I no longer see obvious room for improvement.

Then I would to go github and find same or similar kind of projects, ideally created by companies with strong engineering culture (e.g. Google) and compare how I did stuff to how they do it.

You would be VERY surprised to learn just how much other people would differently solve same problems you have been facing, and you can learn a lot from comparing other people solutions to something you are already comfortable with.