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?
Latest comments (23)
I think the reason people write embarrassing code is not because they're inexperienced. When I look back at my earlier code I'm sometimes impressed with how clean it is.
If you look back and your code was awful, you're skills are probably still terrible. Logic, order and simplicity aren't language features. Performance and scalability follow rational thought.
Write what you encountered first time in the programming world.
Read the book Clean Code by Robert Martin. Start absorbing the knowledge and practices from the book and you'll naturally grow in a way that ensures your code is cleaner and easier for you and other devs to adjust 6 months down the road.
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.
Start building your own libraries.
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.
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.
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.