No. I was kinda onboard until the very end, and was even going to share this with a few juniors I know. The marketing spiel killed it.
Yes, most of these are good steps. Having a plan and a strategy is a great idea, and it will definitely streamline things a bit. Have goals - reasonable ones - and make a plan to attain them. Hell, that's a good 75%+ of the development process right there, and code and frameworks are secondary.
The whole "Forget...." part is junk. If someone wants to write a technical blog then by all means do so! Do it on WordPress or Jekyll and GitHub or whatever the flavor of the week is. Some of the best advice I've gotten was back when I tried blogging and someone came on and told me how wrong I was. (Not trolling either - it was legitimate.) And trying to explain something is a good way to see if you really know what you're talking about; you sit there and think it over, see what needs to be changed and then you figure out how to change it.
Nobody I know buys heavy programming books anymore. (And it's a damned shame in my opinion - I used to love picking out a book and getting excited about the contents, and now I can't justify paying $60 for something I can Google and find a crap ton of tutorials and articles for free.)
Why not spend time on HackerRank? Hell, check out exercism, and Rosetta code also. Solve problems! Then solve them again - differently. Use a different language. Do it in a functional style instead of OOP. Or procedural. Try to do it in Prolog, or SQL stored procedures. Is it going to directly benefit your career? Probably not - I doubt anyone is looking for a string reversal algorithm written in pure ANSI SQL. But it'll give you a different perspective, a different approach.
There's no real shortcut. How do you become a better coder? By coding. By solving problems. By deploying something, watching the errors flood the logs, then picking yourself up and fixing them, rinse and repeat. You can make the process more efficient, but you still need time in the trenches.
100%. There really isn't. One of my favorite articles is by Peter Norvig, the article titled "Teach Yourself Programming in Ten Years": norvig.com/21-days.html
I want to preface by saying there are many other ways to become a developer — not just a single, linear path. Can you go back to school and learn computer science? Sure, that's one way. But that's not the only way. Can you go through some six month boot camp? Probably ... but it all depends on what type of developer you want to become.
But as the (other) Matthew pointed out, you need to code. A lot. But not in isolation. No No. Find yourself a mentor — we all need at least one. The more, the better. Without solid mentors in my corner, there's zero chance that 5 years ago I would've been able to become a software engineer at Amazon Web Services.
Not only mentors, but find other folks who are on a similar journey. That was my regret: working on becoming a software engineer in isolation.
Thanks for that link - I know I'd heard both 10 years and 10,000 hours before, just couldn't remember where. Even without that as a basis I'm still surprised when I see job postings for a senior developer, requiring 5 years experience. I know some awesome coders with that much time, and they'd be great mid-level, but I'd be wary of having them as seniors. They may be great at it, but 5 years isn't enough time to get a lot of solid experience under your belt.
And yes - mentors are definitely important. I learned that the hard way. The main advice I got from my first "mentor" was always "I'm busy, here's a book about that." I've tried damned hard to not be that guy. It made me pretty self-sufficient, but I wonder sometimes how things might've been if I'd had someone who was a better guide, for both tech and career.
Yea it's definitely difficult to categorize people into mid or senior levels based solely on the number of years of experience. Using my most recent employer (AWS) as an example, I've seen "mid-level" engineers with 15 years of experience and also seen more junior engineers get promoted to "senior-level" within 4 years. Definitely depends on the organization. For me, personally, it'd be difficult to consider someone as senior without 10+ years of experience. The reason being is it takes a significant amount of time to be exposed to different problems. One person can have 10 years of experience but solving the same problem — or different problem with the same solution — over and over and over again.
It made me pretty self-sufficient, but I wonder sometimes how things might've been if I'd had someone who was a better guide, for both tech and career.
Being a great mentor is an art. Although I tend to take a Socratic approach when answering questions, it's not always effective. Sometimes, people just need to be told to "read x ... do y." Context is everything. And answers do depend on the person. In some situation x for some engineer y, I might say "go read z." For that engineer, the lightbulb will go off in their head. But for others, they might require a little more hand holding.
So yes, a balance between wanting someone to be self-sufficient but not wasting too much time unnecessarily spinning their wheels (I'm often guilty of this).
If someone wants to write a technical blog then by all means do so!
This isn't really a counterargument. If you want to do so, nobody is telling you not to (including the author). The article is telling you not to write a blog if you're specifically doing it to become an expert from a beginner stage, or at least that's what I understand.
Fair enough, but in light of the remainder of the article I took it as "forget about doing these things, they won't help - my services will!" If anyone thinks that writing a tech blog - or any such focused-content blog - will take them from beginner to expert they're going to be sorely disappointed. (Well, it might help them along the way as a writer or communicator, but even that's not very likely.) You'll get an added benefit from researching topics, or getting feedback if you're lucky enough to get legitimate feedback and not just trolls or spam. It won't take you from asking "what's a compiler?" to principal r&d engineer at Google though.
Matthew, of course writing a blog is a great exercise for any developer and almost a must after a few years writing code. Yet, timing is crucial. If you are just starting out oh only a few years in your dev career you are better off working on those skills. Seeing big and small projects fail and succeed and building the backbone of your technical career. The software community is one big noisy pothole right now, this article is intended to cut through the noise. And of course if someone wants expert help, I believe they would definitely benefit from my services :) Cheers
After some experience in the field, maintaining a blog is a good way to share your knowledge and showcase your work.
From a beginner standpoint, blogging could be used to chronicle your developer journey.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
No. I was kinda onboard until the very end, and was even going to share this with a few juniors I know. The marketing spiel killed it.
Yes, most of these are good steps. Having a plan and a strategy is a great idea, and it will definitely streamline things a bit. Have goals - reasonable ones - and make a plan to attain them. Hell, that's a good 75%+ of the development process right there, and code and frameworks are secondary.
The whole "Forget...." part is junk. If someone wants to write a technical blog then by all means do so! Do it on WordPress or Jekyll and GitHub or whatever the flavor of the week is. Some of the best advice I've gotten was back when I tried blogging and someone came on and told me how wrong I was. (Not trolling either - it was legitimate.) And trying to explain something is a good way to see if you really know what you're talking about; you sit there and think it over, see what needs to be changed and then you figure out how to change it.
Nobody I know buys heavy programming books anymore. (And it's a damned shame in my opinion - I used to love picking out a book and getting excited about the contents, and now I can't justify paying $60 for something I can Google and find a crap ton of tutorials and articles for free.)
Why not spend time on HackerRank? Hell, check out exercism, and Rosetta code also. Solve problems! Then solve them again - differently. Use a different language. Do it in a functional style instead of OOP. Or procedural. Try to do it in Prolog, or SQL stored procedures. Is it going to directly benefit your career? Probably not - I doubt anyone is looking for a string reversal algorithm written in pure ANSI SQL. But it'll give you a different perspective, a different approach.
There's no real shortcut. How do you become a better coder? By coding. By solving problems. By deploying something, watching the errors flood the logs, then picking yourself up and fixing them, rinse and repeat. You can make the process more efficient, but you still need time in the trenches.
100%. There really isn't. One of my favorite articles is by Peter Norvig, the article titled "Teach Yourself Programming in Ten Years": norvig.com/21-days.html
I want to preface by saying there are many other ways to become a developer — not just a single, linear path. Can you go back to school and learn computer science? Sure, that's one way. But that's not the only way. Can you go through some six month boot camp? Probably ... but it all depends on what type of developer you want to become.
But as the (other) Matthew pointed out, you need to code. A lot. But not in isolation. No No. Find yourself a mentor — we all need at least one. The more, the better. Without solid mentors in my corner, there's zero chance that 5 years ago I would've been able to become a software engineer at Amazon Web Services.
Not only mentors, but find other folks who are on a similar journey. That was my regret: working on becoming a software engineer in isolation.
Thanks for that link - I know I'd heard both 10 years and 10,000 hours before, just couldn't remember where. Even without that as a basis I'm still surprised when I see job postings for a senior developer, requiring 5 years experience. I know some awesome coders with that much time, and they'd be great mid-level, but I'd be wary of having them as seniors. They may be great at it, but 5 years isn't enough time to get a lot of solid experience under your belt.
And yes - mentors are definitely important. I learned that the hard way. The main advice I got from my first "mentor" was always "I'm busy, here's a book about that." I've tried damned hard to not be that guy. It made me pretty self-sufficient, but I wonder sometimes how things might've been if I'd had someone who was a better guide, for both tech and career.
Yea it's definitely difficult to categorize people into mid or senior levels based solely on the number of years of experience. Using my most recent employer (AWS) as an example, I've seen "mid-level" engineers with 15 years of experience and also seen more junior engineers get promoted to "senior-level" within 4 years. Definitely depends on the organization. For me, personally, it'd be difficult to consider someone as senior without 10+ years of experience. The reason being is it takes a significant amount of time to be exposed to different problems. One person can have 10 years of experience but solving the same problem — or different problem with the same solution — over and over and over again.
Being a great mentor is an art. Although I tend to take a Socratic approach when answering questions, it's not always effective. Sometimes, people just need to be told to "read x ... do y." Context is everything. And answers do depend on the person. In some situation x for some engineer y, I might say "go read z." For that engineer, the lightbulb will go off in their head. But for others, they might require a little more hand holding.
So yes, a balance between wanting someone to be self-sufficient but not wasting too much time unnecessarily spinning their wheels (I'm often guilty of this).
This isn't really a counterargument. If you want to do so, nobody is telling you not to (including the author). The article is telling you not to write a blog if you're specifically doing it to become an expert from a beginner stage, or at least that's what I understand.
Fair enough, but in light of the remainder of the article I took it as "forget about doing these things, they won't help - my services will!" If anyone thinks that writing a tech blog - or any such focused-content blog - will take them from beginner to expert they're going to be sorely disappointed. (Well, it might help them along the way as a writer or communicator, but even that's not very likely.) You'll get an added benefit from researching topics, or getting feedback if you're lucky enough to get legitimate feedback and not just trolls or spam. It won't take you from asking "what's a compiler?" to principal r&d engineer at Google though.
Matthew, of course writing a blog is a great exercise for any developer and almost a must after a few years writing code. Yet, timing is crucial. If you are just starting out oh only a few years in your dev career you are better off working on those skills. Seeing big and small projects fail and succeed and building the backbone of your technical career. The software community is one big noisy pothole right now, this article is intended to cut through the noise. And of course if someone wants expert help, I believe they would definitely benefit from my services :) Cheers
After some experience in the field, maintaining a blog is a good way to share your knowledge and showcase your work.
From a beginner standpoint, blogging could be used to chronicle your developer journey.