Don't fall for the memes. The overlap between what people talk about online, and what people are succeeding with in industry are way way smaller than you think.
Some people can't be bothered to blog. Some people aren't allowed to blog. Some people are paid to write blog posts they know are bullshit bad advice.
I wish I knew that 'superficial' expertise at a particular technology isn't a pre-requisite for most tech jobs. Two years back, I was invariably anxious about not knowing Angular / Rails / Django and how it disqualified me from getting my foot in the door in many companies.
I later realised, how daft it would be for any company to have a stringent demand for knowledge in framework / library without putting the general "getting-things-done" talent into the equation. The sheer velocity of the changing landscape makes it a horrible way to judge an engineer. Additionally, I wish I knew that soft skills in communicating well, giving feedback, and understanding business goals make up for more points than a breadth of tech skills.
Adding onto this, overly focusing on a technology can really hamper you while getting jobs later. I want to see that you understand the technology that underpins what you will be doing everyday, not the specific libraries that we'll probably abandon in 2 years anyway. Knowing Angular is a lot less important to me than being an expert in the actual javascript language underneath it.
Similarly, it's even more impressive to have a thorough understanding of what's under the hood of javascript, knowing WHY it has it's limitations, instead of just what they are.
Depth of a single, particular subject will never beat depth of an entire stack (before hitting the point of ridiculousness, of course).
Here are some mistakes I've made as a junior engineer:
- Not checking code well enough when working in a new and unfamiliar language (I broke production)
- Not negotiating my salary (almost took a massively underpaid job)
- using an obscure technology when I should have used something mainstream
The list goes on...
I'm writing each of my mistakes up as a weekly email, so if you want to avoid all the mistakes I've made in 20 years of software engineering check out https://softwareclown.com
You need excellent communication skills to become an excellent coder.
You need to clearly describe bugs for other developers, write documentation, explain why a particular technology / framework / pattern is the best choice, understand what a client / product manager is wanting... the list goes on. Eventually, you will hopefully be training and supporting other developers.
How much of your time will be spent coding and how much will be spent communicating with others about your code?
As a junior developer, I overvalued minimizing development time and maximizing correctness. It turned out that writing code for other people to read and modify was a more difficult skill to improve, was more rewarding when successful, and enabled entire teams to move faster. It also turned out that focusing on improving the experience for my team actually improved my personal development more rapidly than before.
If I could send a message to my past self, it would be, "Empathize with coworkers, customers, and family. Everything else will follow."
If you don't have the resources you need to complete a project, don't be afraid to speak up. If the documentation for a project is in another language, it is far cheaper for the company to pay for professional translation than for the project to putter along and fail as you struggle with google translate.
Similarly, if the end-goal of a project is not clear, don't be afraid to stop things and ask.
Judge new tools by the quality of documentation and how possible it is for you to get a clear mental model.
In interviews, always as what their onboarding process is.
If someone asks for a time estimate and you don't know the answer, don't let them pressure you into lying. Hold your ground and say you don't know.
Your first two and last points should included an implicit "Don't be afraid of being shown the door", or "Don't be surprised if your complaints are essentially ignored" and you might as well leave.
I.e make it a highest priority to build enough of a finical cushion that doing these things are even an option.
In regard to various software engineering literature and quotes (hofstadter's law, mythical man month, etc) while there's some truth in what they say, what you'll take away is absolute lies.
- Just because you can't reliably estimate a project doesn't give you an excuse to refuse to give an estimate. We get it, your estimate will be off. Whats important is that you communicate deadline changes early and often.
- Contrary to everything you hear, software projects can be finished on time. Most of the time we procrastinate at the start of a project and crunch at the end. Stop procrastinating at the start and more projects will be completed on time. Which brings me to...
- If you fail to complete a project on time and failed to communicate this impending delay early, this is 100% your fault. This isn't the fault of some stupid law, or book you read. You slacked off and as a result couldn't reliably see how much work was involved in the project and by the time you realized it was probably too late. This is on you.
Many people don't get it. And if you genuinely don't know, then how is claiming you do anything other than writing a cheque against an account of unknown balance? If you feel like you don't have a good handle on how to estimate the project, that is an important sign that:
- The scope of the project is actually not well defined.
- The tools you are going to be using are ones you don't have a lot of experience with and you have a high probability of running into an odd bug that takes a long time to track down
- You haven't broken down the task enough.
- The task is large enough that you should actually be biting off a smaller piece of it and estimating that.
If you think that there is a significant chance of missing a deadline, you should indeed communicate that as soon as possible. That includes during the meeting where you give your estimate.
> Stop procrastinating at the start
If you find that you do actually have a bunch of time that you're losing at the start, ask yourself what the causes of that are and seek solutions to those causes.
- Consistently get good food every day and good sleep every night
- Make sure that you are clear on the projects' goals and the tools you are going to use.
- Make sure you know whom you can go to when you need to get clarification on things.
But be aware that there are other causes for deadline slip.
> this is 100% your fault
If you find yourself in on a software team or a state of mind where your top-of-mind question is "who's fault is this?" get out of there. Pointing fingers prevents organisations from making systems-level changes to avoid them.
Furthermore, if you get yourself into the mindset of "I failed and am behind on this project and it is my fault and I need to just buckle down, catch up, and fix it." then you will not do yourself or the project any favors. Take a deep breath (or even a brief walk), find a senior engineer that you trust, and ask for their help in thinking about how the project is structured and how it might be estimated.
Second point is huge. Not sure what it was about my junior dev self and the horrors that lied beyond that `src` folder.
As soon as I got over that and started inspecting the source of different projects I was using, I definitely became more confident in my own development skills by comparison, and I became instantly more valuable with the libs I was using because I had more control/understanding of what was actually happening behind the scenes.
I still have problems with the second one, as I assume I'm unworthy of reading the code of programmers Much Better Than Me, for fear I'd try something tricky and mess everything up.
I'm also mostly a .Net guy right now in a very .Net area, and they generally frown on that sort of thing until very recently. Not an excuse I know, but just for background.
Learning to read code is a hell of a lot harder than learning to write it. It takes practice, patience and ultimately a language with a high quality working debugger. Once you learn to read code in one language it isn't hard to learn to read it in another.
Love your IDE/editor, and make sure that you have split views (viewing parts of the same file or two files at once). This feature is essential to being able to read code!
Figure out the difference between "I wouldn't do it that way" and "this code is bad". It isn't terribly hard to leap from one to the other.
Find a mentor! I can't stress this one enough. That guy (or gal though they are rare) pushing fifty who is still an engineer, they are that good, don't want to manage, love their craft, and have seen some shit. They will talk your ear off (probably) for coffee.
Lastly writing code is part of the job, once you have master that learn everything you can about your business. Spend time with accountants, CS people, Systems Admins, the IT guys... they are all going to teach you things that will make you better at your job.
Once you've finished learning anything new, and your job is becoming significantly more routine, start looking around for the next job (with a pay rise). Rather than learn new things on your own a few hours a week, you can get paid (more) to learn new things at work for many hours a week. Three significantly different jobs over ten years will make you far more competent than the same job for fifteen or even twenty years.
If you get to five years in the same job, take a long hard look at yourself and check that you are actually still learning and still making yourself more valuable and still improving (which I would expect to really only happen if you weren't actually doing the same job as you were in the first of those five years).
Unit and integration testing not only make code less buggy, but lead to a calm state of mind.
Bugs show themselves quickly, along with which method is failing, so the fixes are fast and effortless when you break stuff. Massive refactoring doesn't scare you, and you sleep soundly with no fear of hidden breakages after each new release.
Don't use a framework or library until you have written a simple variation of it yourself (ideally, this could apply to everything, but you need to find the correct balance).
That sounds like you would need to do a whole lot of work before you could start writing code that is useful to the business that hires you. If your first job out of uni is working at a company that has built a site in ruby on rails, you shouldn't refuse to handle tickets until you've reproduced rails. Also, if you want to learn backend web development, it is far easier to first work through the djangogirls tutorial and learn how django works and then build a stripped-down version of it.
I would replace it with "Don't add a new framework or library unless you can get a clear mental model of it"
You know, the term "junior developer" is rather new, actually. If anything it used to just be "entry-level".
In any case, I find it most distasteful. No one should accept it as a part of their job title for any length of time, other than out of pure, survival-driven necessity.
Figuring things out is a process. Don't expect to write production-ready code at first run.
Every step of the journey informs the outcome and sometimes the destination. Code and logic change -- so learn to program in ways hat adapt to change.
---
Try new things and concepts in tiny single purpose projects.
---
Ask for help, programmers like to explain things.
---
Ask why from your business users. Multiple times, until you get the context. Once you have the context, you can create freely and come up with better ways to do things. If you don't position yourself in this way, you may end up with people trying to control you like they would a tool or a sock puppet. Having people's hands up your bum is no fun.
---
Fight for uninterrupted focused time. This is your spice and the spice must flow.
Here is some insight that has helped me, some my own advice, some paraphrased from other sources, and I credit the source when I have it in my notes:
- There is no "silver bullet" for managing the complexity of user needs. Instead, (good) software is characterized by not a static state of "solving the problem", but a continuous refinement-- an existential struggle against incidental complexity.
- Have a very positive mindset, and inspire the same in your team.
- Learn your debugging tools well: Get good at Chrome Debugging tools, pdb, visual studios debugger, or whatever the debugging environment is for your project.
- “… never consider your education complete or your opinion above questioning regardless of your title, your years of experience, your awards and accomplishments, or anything else that isn’t rational argumentation or evidence. Retaining a healthy degree of humility, constantly striving for improvement, and valuing objective metrics above subjective considerations will go a long way ..."
(http://www.daedtech.com/how-software-groups-rot-legacy-of-th...)
- Read books. I can especially recommend Refactoring by Martin Fowler and The Pragmatic Programmer as a more introductory text (affiliate links: http://amzn.to/2ekPnTL and http://amzn.to/2ekJQMK). Understanding why and how to do scrum effectively is really important too -- I waited too long to read a book that laid that out for me (http://amzn.to/2ekPxul)
- Eventually, you will have to choose between engineering management and continuing to be close to technology. Trying to do both is a recipe for burnout. Some people might be able to do both simultaneously without trouble, but you're probably not one of them.
- Always be looking for ways to remove yourself as a bottleneck. This needs to be done both on a technical level and on an organizational level.
- Push back as necessary against demands of your time and energy that are not in harmony with your needs as a technologist.
- Good programming comes from good habits. (in that vein: copy-and-paste is the devil.)
- Seriously, read books. It's incredible how much good advice is out there.
>- Good programming comes from good habits. (in that vein: copy-and-paste is the devil.)
Hardly.
Copy-and-paste is fine if you understand how and why it works. Magic is bad but forcing yourself to needlessly re-invent the wheel is a dumb idea in itself.
figure out who makes the decision on your raise/bonus, and make sure you nurture a positive relationship with that person. usually your boss; maybe a group of managers, etc.
[+] [-] forgottenpass|9 years ago|reply
Some people can't be bothered to blog. Some people aren't allowed to blog. Some people are paid to write blog posts they know are bullshit bad advice.
[+] [-] namenotrequired|9 years ago|reply
[+] [-] shubhamjain|9 years ago|reply
I later realised, how daft it would be for any company to have a stringent demand for knowledge in framework / library without putting the general "getting-things-done" talent into the equation. The sheer velocity of the changing landscape makes it a horrible way to judge an engineer. Additionally, I wish I knew that soft skills in communicating well, giving feedback, and understanding business goals make up for more points than a breadth of tech skills.
[+] [-] foobarchu|9 years ago|reply
Similarly, it's even more impressive to have a thorough understanding of what's under the hood of javascript, knowing WHY it has it's limitations, instead of just what they are.
Depth of a single, particular subject will never beat depth of an entire stack (before hitting the point of ridiculousness, of course).
[+] [-] madamelic|9 years ago|reply
Most of their listings include a "Must have 3 years of experience in Ruby on Rails".
[+] [-] itamarst|9 years ago|reply
- Not checking code well enough when working in a new and unfamiliar language (I broke production)
- Not negotiating my salary (almost took a massively underpaid job)
- using an obscure technology when I should have used something mainstream
The list goes on...
I'm writing each of my mistakes up as a weekly email, so if you want to avoid all the mistakes I've made in 20 years of software engineering check out https://softwareclown.com
[+] [-] tahpot|9 years ago|reply
You need to clearly describe bugs for other developers, write documentation, explain why a particular technology / framework / pattern is the best choice, understand what a client / product manager is wanting... the list goes on. Eventually, you will hopefully be training and supporting other developers.
How much of your time will be spent coding and how much will be spent communicating with others about your code?
[+] [-] pattrn|9 years ago|reply
If I could send a message to my past self, it would be, "Empathize with coworkers, customers, and family. Everything else will follow."
[+] [-] afarrell|9 years ago|reply
Similarly, if the end-goal of a project is not clear, don't be afraid to stop things and ask.
Judge new tools by the quality of documentation and how possible it is for you to get a clear mental model.
In interviews, always as what their onboarding process is.
If someone asks for a time estimate and you don't know the answer, don't let them pressure you into lying. Hold your ground and say you don't know.
[+] [-] hga|9 years ago|reply
I.e make it a highest priority to build enough of a finical cushion that doing these things are even an option.
[+] [-] lojack|9 years ago|reply
- Just because you can't reliably estimate a project doesn't give you an excuse to refuse to give an estimate. We get it, your estimate will be off. Whats important is that you communicate deadline changes early and often.
- Contrary to everything you hear, software projects can be finished on time. Most of the time we procrastinate at the start of a project and crunch at the end. Stop procrastinating at the start and more projects will be completed on time. Which brings me to...
- If you fail to complete a project on time and failed to communicate this impending delay early, this is 100% your fault. This isn't the fault of some stupid law, or book you read. You slacked off and as a result couldn't reliably see how much work was involved in the project and by the time you realized it was probably too late. This is on you.
[+] [-] TeeWEE|9 years ago|reply
'finished on time'.... This is the waterfall approach. Its broken in its core. So i also disagree with that.
[+] [-] afarrell|9 years ago|reply
Many people don't get it. And if you genuinely don't know, then how is claiming you do anything other than writing a cheque against an account of unknown balance? If you feel like you don't have a good handle on how to estimate the project, that is an important sign that:
- The scope of the project is actually not well defined.
- The tools you are going to be using are ones you don't have a lot of experience with and you have a high probability of running into an odd bug that takes a long time to track down
- You haven't broken down the task enough.
- The task is large enough that you should actually be biting off a smaller piece of it and estimating that.
If you think that there is a significant chance of missing a deadline, you should indeed communicate that as soon as possible. That includes during the meeting where you give your estimate.
> Stop procrastinating at the start
If you find that you do actually have a bunch of time that you're losing at the start, ask yourself what the causes of that are and seek solutions to those causes.
- Consistently get good food every day and good sleep every night
- Use https://freedom.to/freedom to block HN and reddit.
- Make sure that you are clear on the projects' goals and the tools you are going to use.
- Make sure you know whom you can go to when you need to get clarification on things.
But be aware that there are other causes for deadline slip.
> this is 100% your fault
If you find yourself in on a software team or a state of mind where your top-of-mind question is "who's fault is this?" get out of there. Pointing fingers prevents organisations from making systems-level changes to avoid them.
Furthermore, if you get yourself into the mindset of "I failed and am behind on this project and it is my fault and I need to just buckle down, catch up, and fix it." then you will not do yourself or the project any favors. Take a deep breath (or even a brief walk), find a senior engineer that you trust, and ask for their help in thinking about how the project is structured and how it might be estimated.
[+] [-] awareBrah|9 years ago|reply
- horrible at negotiating and playing it safe
- biggest mistake was probably being afraid to read source code of third party libraries when the docs led me to a dead end. Always read the source
- stop trying to make everything DRY, duplication is better than obfuscation
[+] [-] asidiali|9 years ago|reply
As soon as I got over that and started inspecting the source of different projects I was using, I definitely became more confident in my own development skills by comparison, and I became instantly more valuable with the libs I was using because I had more control/understanding of what was actually happening behind the scenes.
[+] [-] twoquestions|9 years ago|reply
I'm also mostly a .Net guy right now in a very .Net area, and they generally frown on that sort of thing until very recently. Not an excuse I know, but just for background.
[+] [-] kzisme|9 years ago|reply
I use them fairly often to parse things or make things more seamless, but is that the general way people go about solving problems? Is that wrong?
Implementing a OSS library yourself seems overkill, but at what point is it worth writing something yourself?
[+] [-] zer00eyz|9 years ago|reply
Learning to read code is a hell of a lot harder than learning to write it. It takes practice, patience and ultimately a language with a high quality working debugger. Once you learn to read code in one language it isn't hard to learn to read it in another.
Love your IDE/editor, and make sure that you have split views (viewing parts of the same file or two files at once). This feature is essential to being able to read code!
Figure out the difference between "I wouldn't do it that way" and "this code is bad". It isn't terribly hard to leap from one to the other.
Find a mentor! I can't stress this one enough. That guy (or gal though they are rare) pushing fifty who is still an engineer, they are that good, don't want to manage, love their craft, and have seen some shit. They will talk your ear off (probably) for coffee.
Lastly writing code is part of the job, once you have master that learn everything you can about your business. Spend time with accountants, CS people, Systems Admins, the IT guys... they are all going to teach you things that will make you better at your job.
[+] [-] EliRivers|9 years ago|reply
If you get to five years in the same job, take a long hard look at yourself and check that you are actually still learning and still making yourself more valuable and still improving (which I would expect to really only happen if you weren't actually doing the same job as you were in the first of those five years).
[+] [-] mattgibson|9 years ago|reply
Bugs show themselves quickly, along with which method is failing, so the fixes are fast and effortless when you break stuff. Massive refactoring doesn't scare you, and you sleep soundly with no fear of hidden breakages after each new release.
[+] [-] mobiuscog|9 years ago|reply
[+] [-] afarrell|9 years ago|reply
I would replace it with "Don't add a new framework or library unless you can get a clear mental model of it"
[+] [-] kafkaesq|9 years ago|reply
In any case, I find it most distasteful. No one should accept it as a part of their job title for any length of time, other than out of pure, survival-driven necessity.
[+] [-] kasey_junk|9 years ago|reply
Is the complaint about "junior" implying age? I'm trying to understand.
[edit] further is the term "senior" developer also problematic?
[+] [-] andrei_says_|9 years ago|reply
Every step of the journey informs the outcome and sometimes the destination. Code and logic change -- so learn to program in ways hat adapt to change.
---
Try new things and concepts in tiny single purpose projects.
---
Ask for help, programmers like to explain things.
---
Ask why from your business users. Multiple times, until you get the context. Once you have the context, you can create freely and come up with better ways to do things. If you don't position yourself in this way, you may end up with people trying to control you like they would a tool or a sock puppet. Having people's hands up your bum is no fun.
---
Fight for uninterrupted focused time. This is your spice and the spice must flow.
[+] [-] goo|9 years ago|reply
- There is no "silver bullet" for managing the complexity of user needs. Instead, (good) software is characterized by not a static state of "solving the problem", but a continuous refinement-- an existential struggle against incidental complexity.
- Have a very positive mindset, and inspire the same in your team.
- highly reliable websites for small companies: http://www.kalzumeus.com/2010/04/20/building-highly-reliable...
- Learn your debugging tools well: Get good at Chrome Debugging tools, pdb, visual studios debugger, or whatever the debugging environment is for your project.
- “… never consider your education complete or your opinion above questioning regardless of your title, your years of experience, your awards and accomplishments, or anything else that isn’t rational argumentation or evidence. Retaining a healthy degree of humility, constantly striving for improvement, and valuing objective metrics above subjective considerations will go a long way ..." (http://www.daedtech.com/how-software-groups-rot-legacy-of-th...)
- This is a marathon, not a sprint.
- Practical engineering advice: https://www.quora.com/What-are-the-best-kept-secrets-of-grea...
- Read books. I can especially recommend Refactoring by Martin Fowler and The Pragmatic Programmer as a more introductory text (affiliate links: http://amzn.to/2ekPnTL and http://amzn.to/2ekJQMK). Understanding why and how to do scrum effectively is really important too -- I waited too long to read a book that laid that out for me (http://amzn.to/2ekPxul)
- Good programming advice from Kent Beck: https://www.facebook.com/notes/kent-beck/mastering-programmi...
- Eventually, you will have to choose between engineering management and continuing to be close to technology. Trying to do both is a recipe for burnout. Some people might be able to do both simultaneously without trouble, but you're probably not one of them.
- Always be looking for ways to remove yourself as a bottleneck. This needs to be done both on a technical level and on an organizational level.
- Push back as necessary against demands of your time and energy that are not in harmony with your needs as a technologist.
- Good programming comes from good habits. (in that vein: copy-and-paste is the devil.)
- Seriously, read books. It's incredible how much good advice is out there.
[+] [-] madamelic|9 years ago|reply
Hardly.
Copy-and-paste is fine if you understand how and why it works. Magic is bad but forcing yourself to needlessly re-invent the wheel is a dumb idea in itself.
[+] [-] thefastlane|9 years ago|reply
[+] [-] navyad|9 years ago|reply
-- write code then reflect on it.
-- connect to like minded peoples.
-- communicate clearly and effectively to make sure your message is conveyed the way you wanted.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] mpalfrey|9 years ago|reply
[deleted]