Ask HN: How to be a great Junior Engineer?
16 comments
- Do some research before asking a question. At the very least you should google a few keywords and look at the first 5 pages before raising it with someone else.
- Don't ask things you can easily find yourself. I've had junior engineers asking me "does git blah has a flag for ...?". It's disrespectful of that person's time.
- Don't question every tiny little thing you come across. Organisations can't maintain perfection, there's gonna be ugly things and people are aware that there's always room for improvement. Sometimes there is complicated history behind things that look stupid on the surface. Some things are the way they are just because they are. Not everything has some grand reason or justification behind it. Sometimes people keep asking questions like "Why was this written this way? Why was it not written that way? Why can't we make it better? Why can't we make it faster?"
- Remember the ugly crap you are seeing today was someone else's shiny shit some time ago and you are not an exception. The cycle will continue and the perfect little happy function you are writing today that's gonna solve everyone's problems is going to be the next person's ugly crap to rewrite and refactor and clean up after you have moved on.
- Don't ask things you can easily find yourself. I've had junior engineers asking me "does git blah has a flag for ...?". It's disrespectful of that person's time.
- Don't question every tiny little thing you come across. Organisations can't maintain perfection, there's gonna be ugly things and people are aware that there's always room for improvement. Sometimes there is complicated history behind things that look stupid on the surface. Some things are the way they are just because they are. Not everything has some grand reason or justification behind it. Sometimes people keep asking questions like "Why was this written this way? Why was it not written that way? Why can't we make it better? Why can't we make it faster?"
- Remember the ugly crap you are seeing today was someone else's shiny shit some time ago and you are not an exception. The cycle will continue and the perfect little happy function you are writing today that's gonna solve everyone's problems is going to be the next person's ugly crap to rewrite and refactor and clean up after you have moved on.
After 25 years in the industry, and been in the roles of senior engineer, lead engineer, manager, business owner. Here is my advice and thoughts.
Companies, divisions and teams are inherently social and political. Communication is very important. Understanding other people's perspectives, even if you disagree. Keep your emotions in check. Take the high road. Don't assume malice when incompetence is a sufficient explanation. Go out of your way to help other people. It builds good karma that will pay you back. Get to know other people in the company. Talk to them and show interest in them.
Perception is king. The only thing that matters is other people's perception of your you and your work. That said, the best way to increase people's perception you is to be a hard worker. Manage the visibility of what you're working on and look for visible things to do. When a department is being downsized, it's the people who are perceived to be of high value that are retained. Remember that you're being watched, even when you think you aren't. Don't look at porn at work. Don't be the last to arrive at work or the first to leave.
Knowledge should be your main goal at this point. Knowledge increases your value. Learn new technologies. Absorb as much as you can. Become the expert in niche technologies used by your team/company. It is your responsibility to make sure you understand what needs to be done. Don't expect someone to explain it to you. Make an educated guess about what are the relevant for next year and learn those. Code at home. Follow your interests.
Companies, divisions and teams are inherently social and political. Communication is very important. Understanding other people's perspectives, even if you disagree. Keep your emotions in check. Take the high road. Don't assume malice when incompetence is a sufficient explanation. Go out of your way to help other people. It builds good karma that will pay you back. Get to know other people in the company. Talk to them and show interest in them.
Perception is king. The only thing that matters is other people's perception of your you and your work. That said, the best way to increase people's perception you is to be a hard worker. Manage the visibility of what you're working on and look for visible things to do. When a department is being downsized, it's the people who are perceived to be of high value that are retained. Remember that you're being watched, even when you think you aren't. Don't look at porn at work. Don't be the last to arrive at work or the first to leave.
Knowledge should be your main goal at this point. Knowledge increases your value. Learn new technologies. Absorb as much as you can. Become the expert in niche technologies used by your team/company. It is your responsibility to make sure you understand what needs to be done. Don't expect someone to explain it to you. Make an educated guess about what are the relevant for next year and learn those. Code at home. Follow your interests.
Congrats!
Rule #1: Never ever stop tinkering or hacking on your own interests.
Rule #2: The passion to code will come and go, but keep your mind and body razor sharp with quality food/exercise/sleep.
Don't try to reinvent the wheel[1]. Every problem you're trying to solve has probably already been solved.
Verify all of your assumptions - ask questions, and realize the context the answer was given (i.e. the same answer may literally not apply to production vs development enviros or one language/API vs another).
Learn how to debug (this is an art), write tests, formal and informal QA procedures, write documentation, and how to get your code pushed upstream (the process) without breaking the system or anyone else's code.
Even if you've mastered the problem domain, most teams limit the ability to contribute too much the first couple of weeks because you need to earn the trust of your team (usually via a combo of defect-free code, humor, and general geek knowledge). Once trust/confidence in your ability is established, you will have plenty to do, and lots of guidance if necessary. But you may not be able to implement your idea for a new foo() in the product until you have reached that point. But watch out for NIH syndrome too.
Rely on more experienced members to help you organize your code files and assets to begin with - align with whatever the team expects. There are project standards, naming conventions, etc. and most of the time it's not written down. Or self-conflicting / clear as mud.
Don't be the dev that delivers sub-sub-standard code that's full of bugs. It's OK if it happens at first, but understand why it happened (root cause analysis?)
If you get stuck, please ask for help (or pseudo code) sooner rather than later. Like an hour or less. Some team members will be better teachers than others.
Good luck and happy coding.
[1] Consult experienced wheel builders first to make sure that it's your ONLY option.
Rule #1: Never ever stop tinkering or hacking on your own interests.
Rule #2: The passion to code will come and go, but keep your mind and body razor sharp with quality food/exercise/sleep.
Don't try to reinvent the wheel[1]. Every problem you're trying to solve has probably already been solved.
Verify all of your assumptions - ask questions, and realize the context the answer was given (i.e. the same answer may literally not apply to production vs development enviros or one language/API vs another).
Learn how to debug (this is an art), write tests, formal and informal QA procedures, write documentation, and how to get your code pushed upstream (the process) without breaking the system or anyone else's code.
Even if you've mastered the problem domain, most teams limit the ability to contribute too much the first couple of weeks because you need to earn the trust of your team (usually via a combo of defect-free code, humor, and general geek knowledge). Once trust/confidence in your ability is established, you will have plenty to do, and lots of guidance if necessary. But you may not be able to implement your idea for a new foo() in the product until you have reached that point. But watch out for NIH syndrome too.
Rely on more experienced members to help you organize your code files and assets to begin with - align with whatever the team expects. There are project standards, naming conventions, etc. and most of the time it's not written down. Or self-conflicting / clear as mud.
Don't be the dev that delivers sub-sub-standard code that's full of bugs. It's OK if it happens at first, but understand why it happened (root cause analysis?)
If you get stuck, please ask for help (or pseudo code) sooner rather than later. Like an hour or less. Some team members will be better teachers than others.
Good luck and happy coding.
[1] Consult experienced wheel builders first to make sure that it's your ONLY option.
> Learn how to debug
I recommend this book: http://www.amazon.com/Debugging-Indispensable-Software-Hardw...
I recommend this book: http://www.amazon.com/Debugging-Indispensable-Software-Hardw...
You already sounds like you are thinking about the right things. I would say that there is no correct answer, because it all depends on deadlines and how busy the senior developers are, but in general:
you can't ask too many questions, BUT when you do get an answer, write it down!
There is nothing that shows lack of effort when you have to spend your time as a senior developer repeating yourself because the junior developer did not write it down or could not remember it.
That is the only thing I would say to you!
And good luck and keep hacking!
you can't ask too many questions, BUT when you do get an answer, write it down!
There is nothing that shows lack of effort when you have to spend your time as a senior developer repeating yourself because the junior developer did not write it down or could not remember it.
That is the only thing I would say to you!
And good luck and keep hacking!
Before asking questions about the codebase, try to find the answer yourself by reading code and tracing its execution. Don't be afraid to fix problems anywhere you find them. This can be a good opportunity to learn how the system as a whole works.
Participating in code review is great: if they're OK with it, try reviewing senior teammates' commits as well. You can learn a lot by questioning why particular decisions were made, and you might even uncover a bug or two.
Participating in code review is great: if they're OK with it, try reviewing senior teammates' commits as well. You can learn a lot by questioning why particular decisions were made, and you might even uncover a bug or two.
As a junior engineer, you're expected to be able to handle specific tasks, that usually have been specified to some degree, or that follow existing patterns.
This is in contrast with senior engineers, which are expected to be able to handle responsibility for a large system or subsystem, and to be able to design and coordinate execution of work at a larger scope.
In consequence, junior engineers usually are not expected to have necessarily a very broad knowledge of different disciplines, methods and tools; they need to have sufficient knowledge to execute the tasks that will be assigned to them, and the ability to execute them correctly.
One particularly important skill to develop is how long one should try to find out things on their own, before asking for help. Many people fall into extremes -- either ask for specific help at every step (which hints at incompetence for that task) or waste many hours or days following a wrong path when a 5-minute chat with someone could have pointed them in the right direction (e.g. "use this library").
So my advice would be to find out which are the kind of tasks that you are expected to do at this point, which tools (including programming languages, database, web server, etc.) that you need to know, and focus on doing a good job in those specific tasks.
At the same time, slowly start increasing your scope (e.g. by doing reading and playing with different tools in your own personal time).
My main practical advice would be to make sure you understand the requirements of the tasks that are assigned to you. It's very common that senior engineers take something for granted, as obvious, but junior engineers miss those implicit requirements. E.g. "of course it needs to be highly available, fault tolerant, and with sub-millisecond latency, duh!"
This is in contrast with senior engineers, which are expected to be able to handle responsibility for a large system or subsystem, and to be able to design and coordinate execution of work at a larger scope.
In consequence, junior engineers usually are not expected to have necessarily a very broad knowledge of different disciplines, methods and tools; they need to have sufficient knowledge to execute the tasks that will be assigned to them, and the ability to execute them correctly.
One particularly important skill to develop is how long one should try to find out things on their own, before asking for help. Many people fall into extremes -- either ask for specific help at every step (which hints at incompetence for that task) or waste many hours or days following a wrong path when a 5-minute chat with someone could have pointed them in the right direction (e.g. "use this library").
So my advice would be to find out which are the kind of tasks that you are expected to do at this point, which tools (including programming languages, database, web server, etc.) that you need to know, and focus on doing a good job in those specific tasks.
At the same time, slowly start increasing your scope (e.g. by doing reading and playing with different tools in your own personal time).
My main practical advice would be to make sure you understand the requirements of the tasks that are assigned to you. It's very common that senior engineers take something for granted, as obvious, but junior engineers miss those implicit requirements. E.g. "of course it needs to be highly available, fault tolerant, and with sub-millisecond latency, duh!"
Stop tip toeing and acting like you're wasting people's valuable time. You're not. Be fearless, ask for info and get free lessons. Ask to pair. It's all about you.
With that mindset, you'll know the product inside and out. No one will be thinking of you as Jr after a few months.
With that mindset, you'll know the product inside and out. No one will be thinking of you as Jr after a few months.
100000% this. If someone is hiring you as a junior developer, it's because they want to mentor/train you!
I don't see why the junior qualifier would be relevant. A great coder is a great coder. Always try and learn new stuff, be humble, be analytical, help people around you, don't talk shit and so on. If you are worried about how to fit in in your workplace, then that is a different question.
Ask the other engineers on the team these questions!
Every engineer and every team has different styles and preferences, and the only way to learn is to ask (and also work with them for a while). Alternatively, ask if there are any documents that outline established team behavior/culture.
Every engineer and every team has different styles and preferences, and the only way to learn is to ask (and also work with them for a while). Alternatively, ask if there are any documents that outline established team behavior/culture.
If I was a senior engineer on your team, would I be willing to get a beer with you? i.e. the most important advice I have is to make sure you ALWAYS have a good attitude.
People are always willing to praise, help out, and even promote guys with good attitudes.
People are always willing to praise, help out, and even promote guys with good attitudes.
Plus most of the best technical conversations take place over beer. Lots of beer.
Don't be afraid of looking stupid in any capacity.
From a Senior Engineer's (or teammates) perspective - what would be the ideal characteristics of a junior engineer joining your team?
* Asks lots of questions vs. making independent decisions on tradeoffs? * Seeks additional code review vs. pushing a project and getting started on the next? * Self picks projects from the backlog vs. asking after each project what I should work on next?
It's my first time working as a full-time software engineer. I can write the code, but have zero experience in 'this is how a junior dev should approach their role'.
Thanks!