The other day I had this thought and shared it on Twitter
One issue related to growing as a developer is looking back at old code and being embarrassed. Don’t be. Without it, you wouldn’t be where you are. As a bonus, it's a great opportunity to practice refactoring.
Do you have any thoughts you'd want to share with junior or beginning devs?
Top comments (23)
I can say that most of my older code is so bad that it is completely beyond refactoring. I consider it a badge of honor that I can refactor my current code.
I think this is great advice. Looking back at a problem you faced six months ago and realizing how much you've learned since then is huge.
As a bonus, I think you're in a pretty good place if you even have a good idea of how to refactor anything in the first place. It's not the most obvious element of software development.
For those who need some guidance in this area, I like this post a lot:
Refactoring is not so scary
Maciej Posłuszny
That's a very good point, refactoring itself takes practice. That post from Maciej is a great place to start if you're new to it.
A few quick thoughts on this.
1) One of my favorite sayings is "If you look at code from 6 months ago and you aren't embarrassed, you aren't learning fast enough". If you are embarrassed, GREAT! It means you're learning
2) You can't steer a ship that isn't moving. The more you are trying things, doing things, moving forward the more you'll be learning and able to course correct.
3) Everyone has off days... I've been in the industry for 15 years in roles from entry to CTO, and I still have days where it just isn't clicking. If you're having trouble with something, don't think its you - this stuff is hard! Bang your head against it for a while, then go for a run or a walk, or take a shower, or a nap... I can't tell you how many times I've been frustrated by a problem for hours or even days and then the answer comes to me in the shower after a run.
4) Don't hesitate to ask for help, but also don't ask the instant you run into something. You need to bang your head against a problem for a little while before you have the context for someone's help to translate into learning. The length of time to work on something before asking probably varies by person, but my rule of thumb for juniors is 15-30 minutes.
I like #4, but I have found less cases of people asking too many questions, than not asking enough. I have found that, depending on the situation, junior developers feel too intimated to ask questions, especially early on in a position or project. So, as a senior dev, I make it a regular occurrence to reach out to junior devs and see if they have any questions.
Definitely! I probably should have mentioned that, the problem is almost always not asking enough.
For a lot of folks, the 15-20 minute is more to put a CAP on their instinct to keep staring at it rather than to get them to look for longer.
My first site I made back in high school had some images at the top of the page do show off the robotics team I was making it for at the time. Super cool stuff. Look ma! I used an
<img>tag! Thing was, I didn't know about image compression and uploaded raw DSLR photos from the team camera. Home page took a good 10-15 seconds to load even onlocalhost.Bonus: The site had about 5 pages (this was long before I had learned anything about server side rendering or build tools) and so I copy-pasted the
<head>manually into every.htmlfile for the project.Nice! I've been there, my friend.
The advice which I would give them, once you are given a problem to solve, first solve it on a paper.
Design first and then start crunching the code, if you can develop this pattern, you will automatically stumble across many common patterns.
Also try to read some good books on code written by likes of Uncle Bob or Martin Fowler, these guys give you simple and clear advice as regards to your code.
I often refer young developers to my talk, A Field Guide to Common Nerds, which is the fruit of my own novice-level misadventures in programming communities.
youtube.com/watch?v=US0bHcD1HvA
I think the advice I'd give people starting out is to not be afraid to ask questions and to avoid self deprecation.
Questions are important, because there is no point being stuck if someone can help you. I look for asking questions in junior developers because it shows they are learning and working. The one warning sign I look for is if they keep asking the same question - eventually I quit answering it, or assign some homework or tasks designed to pound the answer in.
I think avoiding self deprecation is important because I feel like it devalues you both in other people's eyes and in your own eyes. It might not feel that way - it's a preemptive defense against criticism and feels like armor, but it chips away at your self confidence subtly and insidiously.
When you are new people don't expect perfection out of your code. I, at least, mostly expect to see something that works, and improvement over time. No one is going to give you a letter grade.
I get the feeling that junior developers sometimes feel that they are going to get a harsh teardown of their code or invoke the wrath of a senior developer when they submit. At most, submitting code will get some pointers, some collaborative time to fix it up and a new assignment.
1) Ship it. The best software teams I have worked with focus on shipping.
2) Communicate. It's cliche, but true. If a problem appears to be on the horizon (missing a deadline, over-budget, etc.), it is better to bring it up now than to wait.
3) Write tests, but it doesn't need to be for everything.
4) Red, Green, Refactor...in that order.
5) Occam's Razor. The simplest answer is usually the best. I face more challenges changing code which is over-engineered than I do code which simply uses basic best practices and straightforward refactoring methods. This is because, while maybe the original intention of the over-engineered code was good, a slew of edge cases has made the design indecipherable, and thus, difficult to change. To be fair, I did this as well as a junior dev.
You can do the thing.
Love it.
This!
I can say that i'm just graduated and got a job, now i refactorize a project with 1-2 months and is incredible i can easy fix issues that was very hard before.
I think that real experience is very important.
If someone ask me something like “can you do that x functionality in our project like this?”, and if i don’t know how to do it, ill say, “someone made it possible. so we can also do it.”. ill never say i cannot.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.