So, code little ideas, but make sure you start from the essence of the problem - not the registration/login process, not the new API - start directly from the part that's new and challenging and risky. In this way, when the idea fails, you wouldn't have wasted time building support infrastructure for it.
Also, pick light and flexible tools for exploratory programming - dynamic languages, REPL, etc.
So, fair point. Keep up to date with technology, don’t become obsolete. Sure.
But I don't know about the metaphor. I mean, programmers do practice daily. If you’re coding at work you’re practicing.
More to the point: if the author played in the NFL he’d want the cornerback to do exceptionally well at game time, to practice daily, of course, AND to go home at night and keep practicing to become a quarterback AND a coach because, you know, got to keep up. My guess is that’s not what happens in the NFL.
No, you shouldn't have to work a 40+ hour week and then go home and practice to make a living as a software engineer. But if we want highly performant programmers, we should figure out the best ways to practice (and probably spend less--but more effective--time on production code to balance it all out).
>No, you shouldn't have to work a 40+ hour week and then go home and practice to make a living as a software engineer. But if we want highly performant programmers, we should figure out the best ways to practice (and probably spend less--but more effective--time on production code to balance it all out).
You're coming very close to identifying a major problem with our industry that isn't likely to go away. Yes you absolutely do have to "go home and study" to keep up as a software engineer/programmer. This is due to two reasons:
1. Advancements in technology outpace us
2. We're generally overloaded by management that doesn't understand what we do.
As for #1 there isn't much we can do to change that, and who would want to?
But for #2 it's a major problem. In many cases our 40+ hours have to be filled with coding because of the unrealistic deadlines that are posed on us from managers who don't understand the work.
Most of us are managed by people who have no idea what we do. They want "more more more" in terms of features and gizmos but haven't the slightest understanding of what goes into it. Add in scope creep and wasted time with meetings (that make them look busy) and that adds up to a long work week for a developer. And when you ask for time to study or learn something new, the response is "sure, when things aren't so busy".
This just reinforces my belief that you need passion to do this. You have to love development so much you're willing to put up this stuff, work your ass off and still want to go home and learn more.
Yes and it's also because the projects you'll typically work on in a corporate environment are like maintaining and adding features to boring CRUD apps and your skills will atrophy if you don't actively seek interesting, challenging work on your own time.
Your statement seems to infer that a NFL player only "works" one day a week for about 5 hours, and the rest of their training is done on their own time. I highly doubt your average football player would agree: they are working every time they are in there practicing.
Specifically related to your link - about someone who seems unhealthily obsessed with his job I would note - do you see how there's something in his schedule called Rest? How he is encouraged to unwind and have a social life? His personal motto "Balance in all things"? That's something which is missing from the "programmers should practice" narrative.
Neither the person you are replying to or the OP says you need to work 40+ hours a week and spend 10-15 hours a week practicing. Most things which have long term benefits only require 15-30 mins to do them and see results. (exercise, music, foreign language). It really does build up over time.
I would be interested to hear the opinions (or more accurately, experiences) of developers regarding "practice." I'm beginning my career as a software engineer this summer and I would like to become an "excellent" engineer. Employable, of course, but also the go-to for knowledge in a subset of computer science (let's say natural language processing, for example).
Given I have a very long life (hopefully) ahead of me, what would you say is the best way to do this? Yes, coding is good, but is it the best way? I spend a large amount of time doing side projects, but eventually I'll have a family and other obligations, so I would need higher impact, less time consuming practicing options.
An example of this I guess is how many expert violinists actually "practice" for a surprisingly small amount of time because the practice is so deliberate. What's the equivalent for us?
Nearly everything I do in martial arts is practice for the relatively few times I might spar with someone.
I don't do any skills practice for programming. I've never met anyone who did something equivalent to honing basic movement, practicing balance and similar things.
Reading about the latest programming methods is a good thing and can increase your repertoire but I don't think it's comparable to skills-practice in martial arts or music or something similar. In practices like this, there are fundamental skills that need to be in good shape to allow a person to anything creative in the discipline (I have no idea why expert violinists wouldn't spend significant periods practicing but I know little about that. I know that most music requires significant practice of basic skills to achieve mastery).
My suspicious is that programming is an activity that is strongly connected to the brain's language centers and so mastery of it on the skills-level is simple and the problems with it appear on the judgment and understanding level - which doesn't make it easy, rather gives it that extraordinarily hard quality that we programmers are familiar with.
Also, most skills-practice disciplines are performance arts rather than production processes. Machinist and auto-mechanics also have high skill levels but like programmers they are obligated to show some significant accomplishment for their entire time at work. We can contrast this with a musician or other artist, who if they give an amazingly beautiful performance once a month and have it recorded is considered remarkably successful. In contrast, a programmer gets few accolades if she can just "be a great programmer" for an hour a month - what is instead considered with programmers is their entire output, which puts an entirely different series of pressures and constraints on the programmer.
Brown belt in Brazilian Jiu-Jitsu here. I love coding for some of the same reasons I love training and sparring. It's endlessly complex, so you never run out of new challenges.
Lately I try to master one new concept every year. In 2014 it was monads in Haskell, 2013 lisp macros, 2012 basic functional programming in lisp and F#. 2011-2008 it was web dev, TDD, OO, Python, Ruby, PHP, Java, C#, access forms, basic relational database design, and VB.NET.
The last two years I also take a train to work, and in that time on the ride I've started a streak on github where I post all my practice. I commit at least one commit every day either on a side project, a course I'm taking, or a book with exercises I'm working through. The urge to keep the streak going is a big motivator.
Like with everything, it depends. The way you use time is key to pretty much everything. The right hurdles to go for, for learning, are always the ones where you are outside of your comfort zone and you have to struggle for some number of hours, days, etc. to pick up the concept.
But the other half of that is to have a well-rounded life that will keep you on track. If everything feels like homework, you're stressed or unhealthy, etc., it'll be hard to summon the energy to really struggle with a hard problem. Try slicing up your year into the fractions of time you'd expect to spend working on anything. When you budget it this way instead of making a rigid schedule, you spot opportunities to break away from everything else and spend a week or so just trying to do one thing.
I'm not particularly senior so other people might be able to give you better answers. Nevertheless I would definitely recommend that you do a lot of reading. It really helps to know current technologies and more importantly understand why they exist.
You should also try your hand at developing with technologies that you don't know. It's of course useful and more scalable to read and learn about technologies out there, but actually using or implementing something with them brings your understanding to a higher level in my opinion. After all, you could know that technology X is better for something, but until you actually have gone through the suffering it was meant to solve and then used X to resolve it, you won't really understand it.
>but eventually I'll have a family and other obligations,
Get them involved. I teach my nephews programming and math. I am teaching him javascript right now. I am not good at javascript myself, but it is an opportunity for me to learn.
This is good advice, but it's a bit hard to act on. How does one know when to leverage their existing skills to build something vs spending time learning something new and using it to build something (which might not pan out due to lack of experience with that technology, and which will certainly take longer than using what is familiar)? For me, the biggest investment is that of time... and while he provides ideas for small things to do, in the end one really needs to use a technology to grasp it (which he does say).
I'm a beginning programmer working on a small team. We won't be hiring anytime soon so many of the things he suggests aren't options. I'm lucky in that I've been able to learn a lot of things across the stack. However, our main language is Perl, which isn't the most marketable language anymore.
I have an idea for a useful little site -- something that will look good on a resume, but not something that I can imagine becoming a big money maker of any sort. Do I use my main strengths, my familiar technologies (such as Perl and SQL), to write the site? Or do I choose something that might be an up-and-coming technology (like Node.js or Clojure) even if I can't really find any jobs in my area for them?
I do love learning. I spend downtime at work learning new things, but my time outside of work to actually build stuff is limited. I'm getting a bit burnt out on learning new languages and frameworks... I've wandered between Perl, Elixir, Haskell, Clojure, Racket, Javascript/Node, and any number of frameworks for them. I just want to make something solid, but I'm worried that using my Perl skillset will be more of a short term than a long term gain.
I know there's probably no easy answer to this question. But it seems to me that it's better to have made something and launched it (even if it doesn't use the sexiest tech) than to have something half-finished stagnate because I don't have the time to learn the ins and outs of the quirks behind some new tech. Does anyone have any insight into handling this? Thanks.
I've had the same quandary as you. Mainly work with Java and Javascript at work, so I wanted to add a purely functional language. I flirted with Haskell, Scala, Node, Scheme and Clojure and eventually settled on focusing on gaining a better understanding of functional programming with Clojure because it has a familiar platform (JVM), syntax I can understand (sorry Haskell and Scala) and it seems like it's going places.
Last year, I maintained a focus on Java and JS because I'm still intermediate level with those and didn't want to distract myself with other languages and paradigms. That was a good choice.
For this year, I've made a commitment that any side projects I do, I do in Clojure. I cheated and started in 2014, but I am liking this way of focusing on a language for a year and doing everything in that.
Maybe once I have more familiarity with more languages, I will feel more comfortable using the appropriate language to solve a particular problem. However, isn't that part of learning? Using a hammer on nails, screws and bolts and figuring out what the hammer is good at and what it isn't?
Great article. This is something I've said pertaining to interviews for years. There has to be advancement in the skills. Doing something every day is not an indicator of improvement.
In fact, sometimes it can be worse. When someone says "Call this person now! he/she has been writing C# for 10 years!". That's great and all but have they been improving their craft over that 10 years, or getting enough work to not get fired? There's an enormous difference. And many times I would run into folks who sunk into a rut and did the same thing for 10 years basically "coasting". They make small incremental changes in what they do every day, but weren't out seeking ways to drastically improve.
Programming is different than many other fields simply because it requires passion to survive. If you look at learning new things like "Ugh, I have to learn ___", eventually you'll start slipping and end up hacking PHP Wordpress installs somewhere for subpar wages if you're employed at all. If you seek out new things to push yourself because it's enjoyable keeping up is intuitive and easy. Even stuff you may never use for your job can teach you new ways of thinking.
Now if you'll excuse me I need to go back to playing with RUST.
With the speed of technology changes I think it's pretty hard for programmers to get stuck in the exact same rut for 10 years.
Using your example of C#, there has been huge changes in the last 10 years to the point that it's barely the same language.
Even if you imagine the most staid company that refuses to upgrade their tech stack, the last 10 years has seen so many changes in the web and mobile that it's hard to imagine that there hasn't been some pressure on even the most unmotivated programmer to learn new skills.
That's why I mentioned iterative changes, such as the changes to C# over the last 10 years. Just because they started using generics at some point doesn't mean they've been learning anything to drastically improve their code.
It's very easy to sit at a company building calendar apps for ten years and fall behind the rest of the world. I see it every day.
This is a very long way of saying: you should learn new skills, and practice the skills that you think will be valuable by the time you need to get a new job.
Practice isn't rocket science... heck, just practice different kinds of programming. You'll naturally improve at everything because it all relates to each other. To borrow from his football and music examples, even practicing dance will make you a better football player, and so will playing the drums for a cellist.
1. trying many new things
2. in a very tight feedback loop
So, code little ideas, but make sure you start from the essence of the problem - not the registration/login process, not the new API - start directly from the part that's new and challenging and risky. In this way, when the idea fails, you wouldn't have wasted time building support infrastructure for it.
Also, pick light and flexible tools for exploratory programming - dynamic languages, REPL, etc.