If I have Doc Brown's DeLorean, this is what I would advise my younger self
Keep your head down during code reviews. Humility goes a long way. They're not criticizing you, it's your code they're after. It's not personal
Do the required reading before you get knee-deep in the code. You have a propensity to shoot from the hip, curb that enthusiasm. Don't read the manual only when you're in trouble
Design patterns are nice, but you don't have to use all of them, all the time in every code you write
Learn Python early. Get to the Python REPL and type import this. Learn it by heart, then read no. 3 (above) again
Coffee, pizza and chips are nice now, but 20 years from now, you're gonna wish you didn't eat those
In a couple of years, social media is gonna be big. Stay out of it
Those math subjects you hated, better get more comfortable with them. There's gonna be a thing called "machine learning", it's gonna be big, you're gonna need them maths
Stop wondering when you will graduate from being a junior, you'll know it when you're out of it. When you start making technical choices and you recognize that there are choices to be made; then you're not so junior anymore
Be polite when asking questions. If you don't want to get the RTFM response (a lot), read Eric Raymond's guide on how to ask smart questions
When you go to a meeting, always bring a pen and paper. Write your notes
If it's taking you more than 3 hours to figure out something, ask for help, tell your tech lead what's eating you up (but make sure that before you do this, you've read no. 9 above)
If you promised your tech lead (client, coworker or boss) you will deliver the thing on Friday, and you're not gonna make it, tell them early. Don't tell them on Friday
Exercise. You're brain (and your blood pressure) will love you for it
When the book "Pragmatic programmer, journeyman to master" comes out. Read it
From time to time, write a program in LOLCODE, don't lose your humor
Johannes is a Backend and Systems Engineer by trade and works at Microsoft since 2019 to help game studios across the globe implement Online Game Services on Azure.
Design patterns are names for common solutions to common problems and therefore often just a label to shorten a discussion. Do not apply a pattern for the pattern's sake, but apply the right pattern to fit a given problem.
He's basically saying "fit the solution to the problem, and don't over-engineer". Not everything needs a design pattern, so sometimes just keep it simple, avoid abstraction layers if possible, and don't optimise prematurely.
So there's the tongue-in-cheek (ish) advise. Levity aside, let's look at another angle of the question. How does one get out or graduate from being a junior to something else; a senior, I suppose. This is an age-old question and a lot of brilliant minds tried to answer this (I'm pretty sure, a lot more brilliant minds in the future will still try to answer it), this is my favorite so far Programmer Competency Matrix.
Some of the item on the matrix might be abstract but some can get hairy detailed. I don't agree with all of it, but (at least) where I work(ed), there seems to be a general agreement on it. Take it with a grain of salt; remember, you found it on the internet
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.
If I have Doc Brown's DeLorean, this is what I would advise my younger self
import this. Learn it by heart, then read no. 3 (above) againThere's a lot more, but these are my big ones
Please Sir be my mentor.
I'd love to, but I'm terrible mentor. Thanks though
Ok sir,though u don't sound like u will be a terrible mentor, but i respect your decision.
Okay Sir, though you don't sound like one who would make a terrible mentor, but I respect your decision.
Please post repeated architecture and production information,thank you
Can you explain the point 3. I thought using design pattern is a good code practice.
Design patterns are names for common solutions to common problems and therefore often just a label to shorten a discussion. Do not apply a pattern for the pattern's sake, but apply the right pattern to fit a given problem.
He's basically saying "fit the solution to the problem, and don't over-engineer". Not everything needs a design pattern, so sometimes just keep it simple, avoid abstraction layers if possible, and don't optimise prematurely.
This is probably the best advice I've ever gotten... ever. Thanks!
This comment needs a "share" button.
Dude, make a post out of this!
I'll get right on it. Thanks
needs a PR.
thanks @Ted_Hagos , i just started out as a junior dev
Here it is
If I knew then what I know now
Ted Hagos ・ Oct 5 '18 ・ 1 min read
Dude thanks for this! I'll be sharing it with some buddies.
Glad you liked it
So there's the tongue-in-cheek (ish) advise. Levity aside, let's look at another angle of the question. How does one get out or graduate from being a junior to something else; a senior, I suppose. This is an age-old question and a lot of brilliant minds tried to answer this (I'm pretty sure, a lot more brilliant minds in the future will still try to answer it), this is my favorite so far Programmer Competency Matrix.
Some of the item on the matrix might be abstract but some can get hairy detailed. I don't agree with all of it, but (at least) where I work(ed), there seems to be a general agreement on it. Take it with a grain of salt; remember, you found it on the internet