4 ms·
If I could go back in time and give myself advice it would be: 0) Nothing is too hard to do, no matter how much those doing it might seem like towering titans
by ZoFreX 9y ago
If I could go back in time and give myself advice it would be:
0) Nothing is too hard to do, no matter how much those doing it might seem like towering titans many levels above you, or how out of your reach it may seem. Nothing is too hard, there are only things that take time, and things that take more time. If you put in the work, those titans will be your peers before you realise it. Of course, you can't do everything. If you want to put in the amount of work needed for some things, you need to focus. That means deciding to not do some things that you want to do.
1) No-one who is serious about programming gives a shit about language wars, they're for fanboys and spectators. People who get shit done are too busy to spend time on that. So don't sweat what language you choose (too much – there is still such a thing as the right/wrong tool for the job) and especially don't worry about the people insulting it.
2) If it's not constructive practice, you're wasting your time. I spent too much time - literally years - spinning my wheels, writing code but not getting any better at it. Make sure you're reflecting, make sure you're improving.
3) (related to #1) seriously stop worrying about choices and just get something done. You don't get things completed by worrying if you're using the right language/framework/library.
Unfortunately I worry that this advice would send me down another bad path and I'd probably need to add on something like:
4) All that said, some languages really are limiting, either in what you can do, the level of concepts you will learn, or straight up teaching you bad habits. Likewise some libraries / tools / frameworks are actually bad. While you should definitely avoid trying to optimise the last % of productivity, you should spend some time to make sure you're not using something highly suboptimal. If after reflection you believe you are using such a language/framework/etc, then broaden your horizons. That doesn't necessarily mean rewriting your current project, maybe do a toy project or some exercises in something else.
- dingo_bat 9y agoRegarding 2, how do you suggest I avoid "spinning my wheels and learning nothing"? Over the last 6 months I've becoming increasingly aware of this problem with me, but I don't know how to fix it.
- skynode 9y agoTake on bigger technical challenges and keep a notebook for writing down new concepts you learn along the way. Of course the notebook could also be in software. But write. It'll help you internalize stuff.
- matt_s 9y agoIf you are writing software, learn design patterns and create some example application using them to really understand where they fit. Doesn't really matter what language - object oriented one would obviously work best. There are also books on architecture and integration patterns. For everything in your tech stack - find out the sweet spot use cases and the ones where really you should use something else. For example with databases - don't repeat your data (aka normalization) is common - when does that not apply? Spinning your wheels would be things like trying new languages, frameworks, etc. for the sake of just trying them out. It's like going to a car dealer and test driving without any real need or intent to purchase - literally spinning wheels :) You might be fooling your brain that it is learning when you are really just trying something new that is nearly the same as something you already know.
- angelbob 9y agoConsider just-you personal retrospectives. Do them at the end of sprints or projects, and consider a weekly one. I do this both professionally and for personal stuff.
- itamarst 9y agoIn addition to what others said, make sure you realize when you're learning or not. If it's painful to do something, you're learning. If it's easy going, you're not learning. More here: https://codewithoutrules.com/2017/04/17/learning-without-a-mentor/ https://codewithoutrules.com/2017/04/17/learning-without-a-m...
- klibertp 9y agoWhenever you set out to write something, write it differently than last time you did it. It takes conscious effort and a lot of getting used to but actually stopping and thinking about alternative ways of doing something is a practice in itself. When you act on these thoughts, you're most definitely practicing, and quite probably improving. This approach scales from the tiniest pieces of code to whole systems. If your last loop was a simple `for` loop, try writing the next one as a call to map function. If your last loop was implemented as map, write a simple `while` the next time. If your last app used Postgres for persistence, use Redis or CouchDB for your next one. If you're comfortable with MVC, use MVVM for your next project. If you're fine with dynamic typing, try using statically typed language or dialect. Seriously - do it. Nobody is going to say anything to you: they all do the same to stay relevant, even if they know it's not the best strategy for a team as a whole. Make it your policy not to repeat yourself and only fall back to the tried-and-true ways of doing things if there are external circumstances which put you under some great pressure. After a couple of years of this, you'll accumulate most of the techniques and skills you could ever need. The techniques and skills I talk about are transferrable between tech stacks to a certain degree, are impossible to learn/master quickly (no matter how intelligent you are the amount of information is simply too great) and really matter in practice. That knowledge is what differentiates senior programmers from others. Anyway, good luck!
- lcfcjs 9y agoWhat you call "Language Wars" I call not wanting to work with a shitty language like Java. It's slow. So it's never the right tool for the job.