Ask HN: How do you keep improving?
91 comments
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.
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.
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.
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.
I remember back before I knew about variables, when I started learning programming, thinking about a programming problem for whole days, and figured out how to store intermediate computed values in MacOSX text fields and retrieve them later (the values was state for the adventure game I was trying to make), and that allowed me to make a lot more interesting things before, I thought I was so clever; and then I remember the epiphany I got when I finally understood that web page talking about variables; I had been reading it daily for months and had no idea what they were and how they could be applied to my programming, then finally it clicked! What a high! Being able to store values without placing hidden text fields everywhere! I don't think I've been more excited ever again since those summer afternoons, even trying to figure out stuff in shower and in bed... I was 11 or 12 stuck with a Mac at home. I didn't have money to buy my own games and back then it was Apple's dark ages so there were hardly any games anyway; I tried to make my own. Was learning difficult? For sure. Was it uncomfortable? In a way. Was it the best and most exciting experiences in my life? Oh you have no idea. (Ok my marriage to my wife comes a close second; in case she reads this one day.)
Something about childhood experiences makes them a lot more intense...
Something about childhood experiences makes them a lot more intense...
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
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
One of my favorite quotes
"I never got that comfortable being comfortable."
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.
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.
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.
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.
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.
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.
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
"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
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.
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.
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!
This is specifically regarding the third point; I agree with the first two!
The OP mentioned architecture - it helps to be a bit of a generalist to learn architecture, as you need to understand different kinds of problems.
I agree -- Being curious is a great way to improve yourself.
Can you please recommend to me blogs on architecture and design patterns?
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.
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.
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.
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.
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.
Is one better than the other?
IMO, its best to be a Generalizing Specialist (T-shaped individual[0]). How to become that is another matter altogether.
I would also suggest reading Mastery by Robert Greene. Though the book is unnecessarily long, the points he raises are pretty good. Reading the anecdotes is also quite interesting.
0 - https://www.forbes.com/sites/andyboynton/2011/10/18/are-you-...
I would also suggest reading Mastery by Robert Greene. Though the book is unnecessarily long, the points he raises are pretty good. Reading the anecdotes is also quite interesting.
0 - https://www.forbes.com/sites/andyboynton/2011/10/18/are-you-...
Good book. I'd also add Pragmatic Thinking and Learning, by Andy Hunt. Different, but a very useful approach to "how to learn".
No.
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!!
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!!
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/
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/
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.
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.
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!
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!
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
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
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.
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.
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!
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!
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.
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.
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.
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.
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.
Few people are actual experts in a domain. It takes years to do.
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.
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.
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.
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.
I get what you're saying and that's one of the reasons the code should be deeply analyzed when you're learning, many times you'll find the answer to why that particular approach was selected. Very often authors point out why other approaches aren't suitable for that speciic purpose, many times theorically or by using abstract concepts.
Analysis here can also mean rewriting it yourself from scratch (perhaps in high-level pseudo-code) the next day. If you can't make the same decisions the author did or understand them, then analyze again.
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.
Once in a while I go back and review some of the work I did that day and look for ways to improve.
How do you use this tool? What have you learned from it?
The tool is launched on boot via launchctl on OS X and runs all the time.
(https://developer.apple.com/legacy/library/documentation/Dar...) It automatically deletes screenshots older than four days. I use it in conjunction with Workflowy and a web app I wrote called Task Ranger (http://taskranger.com) to keep track of how I spend my time and to come up with improvement plans.
Task Ranger gives me the big picture -- e.g. learning new things is my biggest time sync and takes 25% of my working hours. The screenshots + workflowy give me the micro level view -- e.g. studying unfamiliar codebases is 1/3 of this 25% timeslice.
So now that I know learning new codebases takes a lot of time, how can I get better at that? Well one thing I've started doing is creating a txt file containing basically a manually generated tree of the function calls made by a program. It might look something like this:
That's just one small example of something I'm trying. It's an ongoing improvement process that I try to allocate time for. The screenshots are just a helpful view toward understanding where my time goes in more detail.
Task Ranger gives me the big picture -- e.g. learning new things is my biggest time sync and takes 25% of my working hours. The screenshots + workflowy give me the micro level view -- e.g. studying unfamiliar codebases is 1/3 of this 25% timeslice.
So now that I know learning new codebases takes a lot of time, how can I get better at that? Well one thing I've started doing is creating a txt file containing basically a manually generated tree of the function calls made by a program. It might look something like this:
/new_user
validate_form
create_new_user
User(...)
send_welcome_email
load_email_template
pass_to_email_service
That's just one small example of something I'm trying. It's an ongoing improvement process that I try to allocate time for. The screenshots are just a helpful view toward understanding where my time goes in more detail.
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...
[0] - http://www.daedtech.com/how-developers-stop-learning-rise-of...
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.
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.
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.
Just an FYI: there is a great Coursera MOOC on learning how to learn: https://www.coursera.org/learn/learning-how-to-learn
Simply awesome.
Simply awesome.
Just finished it yesterday myself. It gets relinked to in every thread like this but can't be linked to enough.
Stop learning tools, starts solving problems and in the process learn to think in different ways. Learn the fundamentals of computing as everything else is just a new name for the old idea.
1. Maintain a system long term. This teaches you the benefits of alternative approaches the hard way.
2. Change languages. Forcing yourself to use a completely different paradigm can sometimes bring about architectural epiphanies.
3. Focus on data and communications instead of processing.
4. Meditate on and draw inspiration from timeless wisdom (eg. a good fortune database like mine @ https://github.com/globalcitizen/taoup)
2. Change languages. Forcing yourself to use a completely different paradigm can sometimes bring about architectural epiphanies.
3. Focus on data and communications instead of processing.
4. Meditate on and draw inspiration from timeless wisdom (eg. a good fortune database like mine @ https://github.com/globalcitizen/taoup)
Here some ideas that worked for me:
- online classes. Especially those from actual universities rather than Coursera. Coursera is great but often they target a larger audience and the content may be simplified. Personally, I learned a lot from MIT classes (especially distributed systems and operating systems). They have projects that are challenging and really interesting.
- Competitive programming. I found competition in general to be a great way to improve. It's stimulating and there are many resources available. The downside is that it's hard and can be depressing. For instance, it takes me 10 hours to solve the problems in an easy code jam round when some 18 year kids solve them in an hour. Depending on what you want to learn, there are different type of competition. For instance, code jam / codeforces for shorter type of problems. Google hashcode for slightly larger optimization problems. Kaggle for machine learning. I'm sure there are many others.
Actually, learning stuff and improving is the easy part (you just need free time). There are so many resources. The question is more deciding what to learn, and how can it be useful.
- online classes. Especially those from actual universities rather than Coursera. Coursera is great but often they target a larger audience and the content may be simplified. Personally, I learned a lot from MIT classes (especially distributed systems and operating systems). They have projects that are challenging and really interesting.
- Competitive programming. I found competition in general to be a great way to improve. It's stimulating and there are many resources available. The downside is that it's hard and can be depressing. For instance, it takes me 10 hours to solve the problems in an easy code jam round when some 18 year kids solve them in an hour. Depending on what you want to learn, there are different type of competition. For instance, code jam / codeforces for shorter type of problems. Google hashcode for slightly larger optimization problems. Kaggle for machine learning. I'm sure there are many others.
Actually, learning stuff and improving is the easy part (you just need free time). There are so many resources. The question is more deciding what to learn, and how can it be useful.
First of all it's not bad to keep using what you know, if what you know works well and is the right way to do something. Like if you're very good with the delegate pattern, don't throw it out just because you heard closures are Better™.
What I personally do is to use what I know well, and when some code feels clunky or I notice problems with it, I'll google the problem and be open minded about new solutions, even if they're really different. And I do a bit of research on the good ones (like 20 minutes or so), making sure they don't have other flaws and just ensuring they fit my use-case.
Case in point, I'm doing iOS development again for the first time since iOS 3 or 4, and when I started trying to use CAKeyframeAnimation again, it felt a bit difficult and didn't look all that great either. So I googled for ways to animate with a bounce effect in iOS, and found the newer UIView method to animate with a spring effect, and another solution using UIDynamicAnimator which was new to me also.
After like 5 or 6 hours of reading, googling, writing code, deleting code (custom segues turned out to be the wrong way to use it in my case), and lather rinse repeat, I finally ended up with not only a good end product, but the knowledge of how to use several new APIs and several new concepts. During that I also incidentally found out some cool Objective-C tricks that came out since I last used it.
Plus I felt really uncomfortable with understanding how ARC works (previously it felt like just a bit of magic to me), so I used the same principle of googling my questions & concerns about it, read some stackoverflow answers and blog posts for 20 or 30 minutes, and gained a much better / fuller understanding of ARC that gave me a lot more confidence writing code.
What I personally do is to use what I know well, and when some code feels clunky or I notice problems with it, I'll google the problem and be open minded about new solutions, even if they're really different. And I do a bit of research on the good ones (like 20 minutes or so), making sure they don't have other flaws and just ensuring they fit my use-case.
Case in point, I'm doing iOS development again for the first time since iOS 3 or 4, and when I started trying to use CAKeyframeAnimation again, it felt a bit difficult and didn't look all that great either. So I googled for ways to animate with a bounce effect in iOS, and found the newer UIView method to animate with a spring effect, and another solution using UIDynamicAnimator which was new to me also.
After like 5 or 6 hours of reading, googling, writing code, deleting code (custom segues turned out to be the wrong way to use it in my case), and lather rinse repeat, I finally ended up with not only a good end product, but the knowledge of how to use several new APIs and several new concepts. During that I also incidentally found out some cool Objective-C tricks that came out since I last used it.
Plus I felt really uncomfortable with understanding how ARC works (previously it felt like just a bit of magic to me), so I used the same principle of googling my questions & concerns about it, read some stackoverflow answers and blog posts for 20 or 30 minutes, and gained a much better / fuller understanding of ARC that gave me a lot more confidence writing code.
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... 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.
Is this such a bad thing? Maybe I'm just trying to justify my own lack of motivation, but I've never been able to learn anything related to programming, or computers in general, unless I had a reason to. The times that I've learned something have been when there was a tangible goal, or I was working on some personal project that I was interested in.
So I guess if you want that boiled down into a (highly inelegant) technique, it would be: have some personal project that you want to do and stumble through it; by the end you'll have learned a bunch of new stuff. Note: I wouldn't recommend doing this in a professional or safety-critical context...
Is this such a bad thing? Maybe I'm just trying to justify my own lack of motivation, but I've never been able to learn anything related to programming, or computers in general, unless I had a reason to. The times that I've learned something have been when there was a tangible goal, or I was working on some personal project that I was interested in.
So I guess if you want that boiled down into a (highly inelegant) technique, it would be: have some personal project that you want to do and stumble through it; by the end you'll have learned a bunch of new stuff. Note: I wouldn't recommend doing this in a professional or safety-critical context...
There are two simple mental habits required to improve in anything:
1) Recognize blind spots in your knowledge or skill set. Even without acting upon them, knowing what you don't know is a quantum leap ahead of complete ignorance. Anytime you catch yourself accidentally bullshitting an answer at work, it's because this awareness hasn't been grown enough.
2) Fill in those gaps in your knowledge / skillset in small, low-pressure sprints. Make it easy on yourself. People tend to completely avoid things that make them feel uncomfortable or incompetent, so spending even a small amount of time trying to grasp something is a quantum leap ahead of completely avoiding it. After some time, this is how people seem to "know everything": it's not because they're an expert in all things, it's because they spent the 20% of time it takes to get 80% of the results.
Consistency is key. "Most people overestimate what they can do in one year and underestimate what they can do in ten years" - Bill Gates
1) Recognize blind spots in your knowledge or skill set. Even without acting upon them, knowing what you don't know is a quantum leap ahead of complete ignorance. Anytime you catch yourself accidentally bullshitting an answer at work, it's because this awareness hasn't been grown enough.
2) Fill in those gaps in your knowledge / skillset in small, low-pressure sprints. Make it easy on yourself. People tend to completely avoid things that make them feel uncomfortable or incompetent, so spending even a small amount of time trying to grasp something is a quantum leap ahead of completely avoiding it. After some time, this is how people seem to "know everything": it's not because they're an expert in all things, it's because they spent the 20% of time it takes to get 80% of the results.
Consistency is key. "Most people overestimate what they can do in one year and underestimate what they can do in ten years" - Bill Gates
I used to get out of bed half an hour before I set off for work. Now I get up two hours before I set off for work, have some breakfast and do some learning. I think it's helped me to have a set period of time where I study/practice/tinker each day. It means I don't feel guilty about "wasting" my evenings as well.
Start by becoming aware of yourself. Being mindful and aware of your own existence, weakness, strength gives a profound energy to move forward. Once awareness becomes a second nature, you wont see failure as failure nor success as success. It will become a journey.
I am rebuilding myself with this process and taking inspiration from Bhagwad Gita for that.
I am rebuilding myself with this process and taking inspiration from Bhagwad Gita for that.
What makes you think that you are not improving? Programming is a craft where you can make pretty things with old tools as well as new. Do you feel your code works less well, or achieves less than the ones you 're comparing to? Or are you just anxious because you skip learning the newer trends?
Start meditating and stop worrying about improvements.
you have to be something before you can be nothing
Two thoughts from someone without a mentor (if you can get one, do that) -- you asked how I (or we) keep improving, but my first thought is you seemed to figure out your own problems:
1) "...and tutorials seem to move at a way to slow pace, so i mostly skip them".
Either you're doing the wrong tutorials, or give them more credence.
2) What I do:
i) Keep myself exposed to what is out there (Hacker News, Blogs, Twitter)
ii) Make sure I am always reading a book (audio books, usually)
iii) Be aware of the next wave of tech -- what is bleeding edge? (current answer: Machine Learning, VR/AR, Self-Driving Cars, Blockchain)
iv) Find resources to learn them: Coursera, Udacity, local colleges courses, meetup groups.
Either you're doing the wrong tutorials, or give them more credence.
2) What I do:
i) Keep myself exposed to what is out there (Hacker News, Blogs, Twitter)
ii) Make sure I am always reading a book (audio books, usually)
iii) Be aware of the next wave of tech -- what is bleeding edge? (current answer: Machine Learning, VR/AR, Self-Driving Cars, Blockchain)
iv) Find resources to learn them: Coursera, Udacity, local colleges courses, meetup groups.
Find something interesting. If you want to be engaged, it has to be something that engages you. We spend most of our "mandatory effort" energy at school or work. If you have a side project or hobby, it will only happen if it's something you find at least somewhat interesting. Doesn't mean there can't be rote portions, but in general, it should be something you want to do.
Find a small task that you want to accomplish, identify something you want to learn along the way. Proceed to accomplish said task with the new tools.
Find a small task that you want to accomplish, identify something you want to learn along the way. Proceed to accomplish said task with the new tools.
I don't think it's about learning new stuff. Find a really hard problem and work through it. That's how I learned the most. I am not talking about one month projects but something that takes a year or more. In a project of that size a lot mistakes you made at first come back to you over time and you can improve.
My most difficult projects have been done with C++ and took years. That experience still gives me an advantage even with JavaScript because I have developed pretty good instinct about what probably will work or not.
My most difficult projects have been done with C++ and took years. That experience still gives me an advantage even with JavaScript because I have developed pretty good instinct about what probably will work or not.
From your description, it sounds like you're lacking a certain amount of discipline. You mention things you know you should be doing that you're not ("i rarely take the time to lern something in depth", "whenever i sit down i just keep reusing what i know").
I also think that having high standards is important if you want to keep improving.
So they're two general areas I'd suggest working on.
I also think that having high standards is important if you want to keep improving.
So they're two general areas I'd suggest working on.
Join the community and take some classes with https://bradfieldcs.com/
They've got a great set of experienced & knowledgable staff, plus a group of other developers who all care about growing in their careers. Just chatting with the other folks there has been a huge boost in my career.
Practice meta thinking. How can I improve what I'm doing right now? A great side effect is it also reduces boredom on rote tasks.
Try pluralsight. As someone who learns visually and understand why things are the way they are, it is been a godsend.
Occasionally, a couple of times a year, I will challenge myself to learn some new technology and I will utterly immerse myself in that technology until I have a working basic knowledge of it. It is how I learned Emacs. It is also how I learned Vim when I grew tired of Emacs' shenanigans.
I'm not seeking a flame war, but what Emacs shenanigans were those? I mostly use Emacs, so I am just curious. Thanks!
Read other people's code on github/gitlab. Use a bookmarker to manage them.
Then once you pick a project you are really interested in, build something using that as a guide.
> How do you guys keep learning new stuff?
You need a problem to solve. A problem which really matters to you.
> How do you keep improving?
Surround yourself with exceptional people. You will be the product of your five closest peers.
You need a problem to solve. A problem which really matters to you.
> How do you keep improving?
Surround yourself with exceptional people. You will be the product of your five closest peers.
By learning things in-depth and by having the attention-span and learning-wisdom to not skip slow-seeming basic tutorials.
when you have a problem. first solve it yourself. get practical experience and make errors. then read about how other people solved it. make a better solution. write a blog post about it. share your code. argument on forums. teach it to others.
Learn Haskell.
you are an interesting writer
[deleted]
Adderall.
Worst idea ever, stay off the chemical cocktails. It only takes one objective look and a minimum of reflection to see what Big Pharma is up to, and it's not good for anyone. Speed will make you feel better-ish, but it will also turn you into a Zombie-like shell without substance.
I wouldn't recommend drugs at all without knowing more about the person I'm talking to, but I strongly prefer natural alternatives like weed and shrooms to untangle my my brain.
Back to subject. I would say stop worrying so much about what others are doing and trust your own intuition about what to learn and how to do it. Most of software is an ignorant echo chamber, most of the people who make noise couldn't write a creative line of code if their lives depended on it. Do your thing, I'm sure you didn't go through all the effort of coming here to be just another drone.
I wouldn't recommend drugs at all without knowing more about the person I'm talking to, but I strongly prefer natural alternatives like weed and shrooms to untangle my my brain.
Back to subject. I would say stop worrying so much about what others are doing and trust your own intuition about what to learn and how to do it. Most of software is an ignorant echo chamber, most of the people who make noise couldn't write a creative line of code if their lives depended on it. Do your thing, I'm sure you didn't go through all the effort of coming here to be just another drone.
You wouldn't recommend Adderall (a drug with extensive(!) safety research) but instead you would recommend weed and shrooms? Also speed != adderall.
Why on earth would you trust substances humans have been using for thousands of years in favor of something brewed in a lab by a pharma company with quarterly goals and a decade (or two?) of tests (perhaps with incomplete test coverage). Difficult choice.
Just because humans have been using something for thousands of years doesn't mean its a safe choice.
Adderall (a drug with extensive safety research conflict of interest, thus bias). I caught a guest (friend of a friend) snorting Adderall & she looked/acted like a meth addict.
I'm upvoting it because it's incredibly common in high schools and college. People have to do tons of repetitive, boring stuff. They have piles of work. Many turn to Adderall to stay focused enough to get it done.
Like it or not, it's how a huge chunk of people in college "keep improving" despite the challenges they face not getting better over time.
Like it or not, it's how a huge chunk of people in college "keep improving" despite the challenges they face not getting better over time.
I'm not sure that's great advice. Adderall provides a temporary boost but it takes a lot out of you too. Kicking it becomes difficult because you don't think you can be productive or even intelligent without it. This account [1] of a person who got addicted in college and tried for years to kick it convinced me not to try it.
Please think twice before recommending or endorsing any kind of pharmaceutical product.
[1] - http://www.nytimes.com/2016/10/16/magazine/generation-addera...
Please think twice before recommending or endorsing any kind of pharmaceutical product.
[1] - http://www.nytimes.com/2016/10/16/magazine/generation-addera...
"I'm not sure that's great advice. Adderall provides a temporary boost but it takes a lot out of you too. "
I didn't recommend taking Adderall. I'm against it unless it's a last resort where nothing else is working. I upvoted it because it literally is how so many students and workers in America keep moving. Not just that drug but many. So, it's worth being in a survey.
The natural follow-up is asking what kind of work they do or where in case one wants to avoid motivation for such a solution. ;)
I didn't recommend taking Adderall. I'm against it unless it's a last resort where nothing else is working. I upvoted it because it literally is how so many students and workers in America keep moving. Not just that drug but many. So, it's worth being in a survey.
The natural follow-up is asking what kind of work they do or where in case one wants to avoid motivation for such a solution. ;)
> People have to do tons of repetitive, boring stuff.
A good programmer will automate this stuff and will not bother with it again. Maybe aderall is incentivizing the wrong behavior here.
A good programmer will automate this stuff and will not bother with it again. Maybe aderall is incentivizing the wrong behavior here.
You can automate homework and tests for your classes? That's news.
I was referring to programming work only
How do you automate arbitrary programming assignments without cheating by having someone else do them? There were piles of little problems I had to do in programming. It being mundane was obvious when contrasted to better options like having people build a neat app or game piece-by-piece as they go through lessons. Land of LISP comes to mind. Also has amusing artwork.
Studying is repetitive boring stuff.
Not if you do it right.
How do you study mundane, endless trivia "right" where it's not boring or wearing you out? I managed to do what studying I needed to do but it was far from fun. The only times it was fun was when the material itself was fun. It was still work but at least interesting work. Most weren't, though.
Good question. I think a lot of it starts with motivation. If you are just studying something for fun then the boring stuff does get really tedious. But if you are studying for something beyond the subject, eg, in my case it was acing my degree to prove something to myself, then the competitive side takes over.
There are people out there that devote themselves to memorizing decks of cards or arbitrarily long numbers. Cards or random numbers are not particularly interesting, so these folks invent mind games. They may take each card to represent a particular object and then make up some crazy story involving these objects. Suddenly to them what was mindbogglingly dull becomes tantamount to some epic screen play.
You can employ similar tricks to studying any subject. When studying for my degree there were a few things that really helped. Note taking, notes had to be as vivid as possible. I would always have multiple coloured pens and highlights as possible. Pictures, various sized and coloured text and lots of arrows. My notes became art. Mnemonics and stories were important for the long lists of things.
Also managing energy levels is pretty important. Regular sleep cycles, exercise help maintain focus. Environment makes a big difference. A library is much better than the common room.. Also, slightly controversially, I find the often given advice to take regular breaks when studying was highly damaging. If I allow regular breaks, then my focus shifts to watching for when my next break is. Also in the breaks I would get time to think about how dull this stuff was. So I would find maintaining pure focus for about 4 hours at a stretch much easier. It helps to have a variety of studying techniques to move around in. So moving between reading / note taking, mnemonic memorization, doing exercises, visiting tutors, discussing with study partners helps keep things flowing.
There are people out there that devote themselves to memorizing decks of cards or arbitrarily long numbers. Cards or random numbers are not particularly interesting, so these folks invent mind games. They may take each card to represent a particular object and then make up some crazy story involving these objects. Suddenly to them what was mindbogglingly dull becomes tantamount to some epic screen play.
You can employ similar tricks to studying any subject. When studying for my degree there were a few things that really helped. Note taking, notes had to be as vivid as possible. I would always have multiple coloured pens and highlights as possible. Pictures, various sized and coloured text and lots of arrows. My notes became art. Mnemonics and stories were important for the long lists of things.
Also managing energy levels is pretty important. Regular sleep cycles, exercise help maintain focus. Environment makes a big difference. A library is much better than the common room.. Also, slightly controversially, I find the often given advice to take regular breaks when studying was highly damaging. If I allow regular breaks, then my focus shifts to watching for when my next break is. Also in the breaks I would get time to think about how dull this stuff was. So I would find maintaining pure focus for about 4 hours at a stretch much easier. It helps to have a variety of studying techniques to move around in. So moving between reading / note taking, mnemonic memorization, doing exercises, visiting tutors, discussing with study partners helps keep things flowing.
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?