4 ms·
This is awesome! Keep up the good work. As a fellow developer who began writing software around your age, I have some advice that is definitely subjective and b
by gilesvangruisen 8y ago
This is awesome! Keep up the good work. As a fellow developer who began writing software around your age, I have some advice that is definitely subjective and biased, but which you may indeed find helpful.
1. Keep practicing. Practice makes perfect. Explore different languages, frameworks, and problem spaces (interfaces, servers, distributed systems,
statistics, etc.) to see what you find most interesting. You will make mistakes, and that is okay. That is how you learn.
2. Take frequent breaks. Programming is hard work. It can be truly exhausting, and you should not be afraid to step away and go for a walk or something.
3. The most valuable people in the industry are called "T"s. I.e. people with a little bit of knowledge/experience across broad range of topics (the horizontal part of the letter T), but who have deep knowledge/experience in one or a couple particular topics (the vertical shaft of the letter T).
4. Begin to develop the skill of taking feedback and accepting criticism. There's a lot of people out there who will be quick to criticize everything you do if you put it out into the open. It's a whole skill in itself to be able to interpret this feedback and separate the signal from the noise. Try to empathize with the person or group providing feedback and understand that their motives/perspective may be different from yours. Sometimes that's a useful thing. Sometimes it's a distraction.
5. Dn't take things too personally. You are not your code. A criticism of your code is not a criticism of your character. The less you take things personally, the easier it is to work with others. After all, the most impressive systems require immense collaboration.
6. Don't take yourself too seriously. Have some fun with it! Programming is super fun, so you should ask yourself regularly "am I still having fun?". If the answer is "No", maybe find something else interesting to focus on for a bit.
7. Broaden your perspective. Along the lines of #1 and #2, it's important to maintain a broad perspective and push yourself to keep expanding your perspective. This doesn't just apply to technical problem areas or languages or frameworks. The best engineers are good problem solvers because they have a broad perspective not just of the problem space but also more generally of the world they inhabit. Try to learn about different industries, cultures, people, and places. You will become a more well-rounded character for doing so, with a higher ability to empathize with others and understand the complex mechanics of how the world works.
8. Be social. I made the mistake of hiding in my room on a computer for much of my childhood, and it wasn't until high school that I really began to understand the value of social interaction and maintaining strong solid friendships. It's as important to spend time away from the computer as it is too keep practicing.
All the best. Good luck!!
- corpMaverick 8y ago9. Bookmark this page, so you can come back and see the wonderful advice that you got when you were 12. It will make more sense as you get older.
- gilesvangruisen 8y ago:)
- truncate 8y agoI'm 27, and learned this over over years, but still I needed to hear this again! And I'm sure I will need this advice again. Bookmarked :)
- godelmachine 8y agoWould you please provide an example on how one proceed with T shaped learning and expertise?
- Jach 8y agoA phrase I came up with that I like more than "T-shaped" is "molecular skillset". A chemist would probably laugh at me but I think of it as developing seemingly independent skills (molecules <--> skills, experience, knowledge...) that end up forming bonds with other skills, sometimes in surprising ways, that together prove really powerful and can bond up even further. "T" and other tree/tendril-ish shapes are then just special cases of different bond arrangements. You can acquire skills haphazardly (though as a serial dabbler I'd caution against actively pursuing the dabbler's path without a ton of introspection), you can also take the efficient road like a university sequence where most skills are visible and have unsurprising connections to the next skills. You might have to take some seemingly unrelated course too, but you can look at those optimistically as another potential source of surprising bonds. Duds are of course possible -- I have some useless things in my brain that I don't think will ever connect with anything useful, at best they might aid in social signaling one day. (A lot of education is just signaling to show you can talk about a lot of stuff...) Trivial example: at some point around age 17 I installed Gentoo successfully and learned a lot about gnu/linux (and some bsd) in the process. Lots of little skills formed and connected, and they continue connecting with other things to this day. Got my initial hook on vim then. Saw how nicely colorized my terminal prompt was and that opened the door to many bash customizations. One of the skills I had to learn was to understand how hard drives worked (at least to the ability to successfully partition, format, and boot them -- I did accidentally wipe a windows xp partition the first time). Some years later (age 20?) I had accidentally rm'd a couple weeks of java work without having committed it yet. But prior knowledge of the system let me know the data was still there, and I was able to recover it by scanning the disk device partition directly for the bytes. (Ended up using "grope.tcl" referenced here http://wiki.yak.net/592 http://wiki.yak.net/592 which was a lot more efficient than what I was making.)