Ask HN: What is 1 thing that can take a Junior's career to the next level?
64 comments
Telling your manager that you want to be at the next level and what you want to bring to the table.
why?
If that manager is good, they will bend over backwards to give you a plan, hook you up with the right people and ensure that you get that promo quickly.
Why?
Because it makes them look good. Amazing, even.
Understanding the mechanics of the business you work under and talking to people on the profit-side won't hurt, though.
why?
If that manager is good, they will bend over backwards to give you a plan, hook you up with the right people and ensure that you get that promo quickly.
Why?
Because it makes them look good. Amazing, even.
Understanding the mechanics of the business you work under and talking to people on the profit-side won't hurt, though.
Understand what the ego is and how is trying to hold you down.
Not spending all day on HN.
Time.
Why there should be just one thing?
Anyway, assuming programming: https://github.com/braydie/HowToBeAProgrammer
Anyway, assuming programming: https://github.com/braydie/HowToBeAProgrammer
Not calling themselves Junior.
When I read that, I laughed, then realized that is literally all it takes and is exactly how I made the transition.
Humility
Figuring out 'what makes you itch':
https://www.youtube.com/watch?v=khOaAHK7efc
Switch jobs.
Find someone more senior; ask questions; listen.
There is no single thing. There's a grocery list. It starts with:
1. Finish shit on time.
Has a bunch of things that mean: 2...99...: Understand to the best of your ability what you finished, how it fits into your business, and what could be done better.
And ends with the most important rule:
100: Don't be an asshole
edit: 101: proofread what you write
1. Finish shit on time.
Has a bunch of things that mean: 2...99...: Understand to the best of your ability what you finished, how it fits into your business, and what could be done better.
And ends with the most important rule:
100: Don't be an asshole
edit: 101: proofread what you write
Note that "Finish shit on time" is almost a subset of "being able to estimate well". Having mentored and hired more than a few junior devs, if I could stress ONE thing to make them better developers, it would be to focus on figuring out how to estimate accurately.
Estimating accurately has a variety of criteria, like knowing the system you're developing against well enough to understand pitfalls and hurdles, knowing how much time will be spent discussing the task at hand, etc. It's not just "this is how long it will take me to write <x> function"... but it is absolutely critical to getting shit done on time, as it literally helps you define what on time is.
Estimating accurately has a variety of criteria, like knowing the system you're developing against well enough to understand pitfalls and hurdles, knowing how much time will be spent discussing the task at hand, etc. It's not just "this is how long it will take me to write <x> function"... but it is absolutely critical to getting shit done on time, as it literally helps you define what on time is.
On a related note, the concept of "underpromise and overdeliver" is useful to internalize here. Delivering a product early / below budget after a high estimate is usually a lot better than delivering a product late / above budget after a low estimate.
Co-signing this. Showing that you understand the business you're in and being able to propose and build solutions that best fit the business is a good way to get noticed.
Also don't deliver buggy code.
Also don't deliver buggy code.
Proactivity
Less thinking about yourself.
lots of work (classic craftmanship learning cycle (build 1000 potteries as fast a possible, get better each time))
As a frequent mentor of junior developers, having been one myself and managed dozens in my career, the answer is COMMUNICATION.
Technical skills will come naturally over time. But to improve your technical career, you will be working with people who are not technical. Learn how to describe technical changes and aspects in layperson terms. Practice presentation and documentation skills (perhaps even join a group like Toastmasters to improve). Learn to triage issues and set expectations through email and discussion in a rational and calm manner.
Technical skills will come naturally over time. But to improve your technical career, you will be working with people who are not technical. Learn how to describe technical changes and aspects in layperson terms. Practice presentation and documentation skills (perhaps even join a group like Toastmasters to improve). Learn to triage issues and set expectations through email and discussion in a rational and calm manner.
Also, learn to write clear and correct sentences in your primary language. You will communicate better and you will be perceived as more intelligent.
Ship a product. By doing that, you'll have to figure out SO much stuff from front to back. Doesn't even have to be your product, it could be moonlighting project. Just ship something from start to finish.
Being able to ship something is definitely important as there are a lot of junior (and even more experienced devs) that just can't seem to finish a project.
Also, stick around for a while after it's been shipped or deployed and see what kind of difficulties the ops guys have with it if it's a SaaS product or the customer support team has if it's a locally-installed product. There is a huge difference between shipping a working product that is simple to operate and support vs. one that requires constant care from an expensive ops or support team.
Also, stick around for a while after it's been shipped or deployed and see what kind of difficulties the ops guys have with it if it's a SaaS product or the customer support team has if it's a locally-installed product. There is a huge difference between shipping a working product that is simple to operate and support vs. one that requires constant care from an expensive ops or support team.
Make it an iOS app and everything else will seem like cake for the rest of your career, unless someone else figures out a way to make the process even worse. Technical issues can be worked out by anyone, being able to handle red tape issues is a skill most developers don't even want to acquire.
Work with people better than you.
It's just time really.
The amount of time will vary depending on your background, degree, existing experience, and sure enough, luck. But it's just time.
In the current state of the industry, a senior is just "someone who's been around and did/saw some stuff".
It gets a lot trickier after that step. But for a junior, just keep doing what you do and try to do it better while learning/seeing as many things possible. Basically, just give it time.
The amount of time will vary depending on your background, degree, existing experience, and sure enough, luck. But it's just time.
In the current state of the industry, a senior is just "someone who's been around and did/saw some stuff".
It gets a lot trickier after that step. But for a junior, just keep doing what you do and try to do it better while learning/seeing as many things possible. Basically, just give it time.
Interaction. It's what one does, and what the environment does and how the interaction goes. What ever you do in the wrong environment, will not help, and vice versa.
I think questions like this aren't really going to get you the answers you're looking for. There's no one-step fix to becoming a better employee, just like there's no one-step fix for anything. You've likely already heard the advice that will help you improve: be perseverant, work smart _and_ hard, stay organized, and be empathetic.
Fact is that you will get 30 different answers from 100 different people, and even with same answers from different people, you'll get different reasons for why they chose that answer.
No, you won't get some silver bullet that's going to propel you to the top in 5 years. I don't (possibly mistakenly) think that's the point. You're going to get a list of criteria specified on a person-by-person basis that speaks to their personal experience as a junior dev turned senior, a junior rising through the ranks, a senior mentoring lots of juniors, etc. Most of the information given will probably be valid. It is then up to OP to parse through the information, and they'll have to figure out what's most applicable to their situation.
No, you won't get some silver bullet that's going to propel you to the top in 5 years. I don't (possibly mistakenly) think that's the point. You're going to get a list of criteria specified on a person-by-person basis that speaks to their personal experience as a junior dev turned senior, a junior rising through the ranks, a senior mentoring lots of juniors, etc. Most of the information given will probably be valid. It is then up to OP to parse through the information, and they'll have to figure out what's most applicable to their situation.
Take the time to understand the whole system you work within, not just your little stovepipe.
That system may not be technical, but procedural. It will include other business functions. It may include your customers. In any system, there is a clear "start" and "end" that encompasses a complete process and reason for being.
You'll find that in most organizations, people stay in their little corner, do their little thing, not caring much about what happens to the left and right of them. That leads to inefficiencies and missed opportunities.
If you understand the larger system, you'll be able to see opportunities others are blind to. Point a couple out and -if you're both respectful and right - it won't take folks long to think "man, this guy really gets it!"
That system may not be technical, but procedural. It will include other business functions. It may include your customers. In any system, there is a clear "start" and "end" that encompasses a complete process and reason for being.
You'll find that in most organizations, people stay in their little corner, do their little thing, not caring much about what happens to the left and right of them. That leads to inefficiencies and missed opportunities.
If you understand the larger system, you'll be able to see opportunities others are blind to. Point a couple out and -if you're both respectful and right - it won't take folks long to think "man, this guy really gets it!"
I like this a lot. When I first became engineer I went to our infrastructure team to have them explain to me what every tool we have does and how it fits into what we do. It took a few weeks but at the end of it, I could see the way the business ran much clearer than I did before. This helped me tremendously over the next few years.
A great way to do this: join a small startup. I did, and I learned more in the first week than I could have ever hoped to at my old job.
Also related: https://schloss.quora.com/Design-doesnt-deserve-a-seat-at-th...
Also related: https://schloss.quora.com/Design-doesnt-deserve-a-seat-at-th...
assuming both the startup and the "big company" you compare it to are great in their respective categories, I find it to be a wash. My career was split pretty 50/50 between startups and big companies (about half dozen of each as my sample size), I found them to be similar in term of learning. You just learn different things.
At a startup you're more likely to do everything and wear all the hats, see things from the beginning and build stuff from scratch. That also means you don't get to see as much of how tech debt can be efficiently paid off, how to maintain large systems, or can't have the hindsight 20/20 of all the solutions to problems startups face.
My early careers was mostly startups, and I felt I had learnt a ton. Then joined bigger highly successful tech companies, and realized there were much better ways to do everything I had seen (solutions that would have worked at the startup scale in many cases)
At a startup you're more likely to do everything and wear all the hats, see things from the beginning and build stuff from scratch. That also means you don't get to see as much of how tech debt can be efficiently paid off, how to maintain large systems, or can't have the hindsight 20/20 of all the solutions to problems startups face.
My early careers was mostly startups, and I felt I had learnt a ton. Then joined bigger highly successful tech companies, and realized there were much better ways to do everything I had seen (solutions that would have worked at the startup scale in many cases)
This advice echoes the first chapter in The Passionate Programmer. Recommended.
I think the most important factor for my own professional growth has been working with people who know more 'stuff' than me. Every job I've had I've learned _tons_ from my coworkers. I wouldn't know frontend if I hadn't partered with a guy who was a CSS pro, I wouldn't be good with Azure if I didn't work with a guy who was already really good with Azure.
Obviously it takes a lot of legwork on your own part, but having the guidance helps a whole lot.
Obviously it takes a lot of legwork on your own part, but having the guidance helps a whole lot.
In my experience, a familiarity with the command line along with the associated general systems/server exposure will elevate your career faster than anything. For those with such exposure already I'd recommend diving deeper and become an expert in the tools your existing team uses for systems, release, and deployment. These skills also open up new career paths you may opt for in the future.
While most of us are probably comfortable enough running make/grunt/gulp/etc, that comfort typically stops there. Knowing how to set up and manage your own systems will both make you more useful on your team and visible in the org. This is especially true for junior front-end folks.
While most of us are probably comfortable enough running make/grunt/gulp/etc, that comfort typically stops there. Knowing how to set up and manage your own systems will both make you more useful on your team and visible in the org. This is especially true for junior front-end folks.
100,000 hours of practice. The easiest way is to ship products. When you feel like you've somewhat mastered whatever you are currently doing look for opportunities to learn a new framework, language, platform, etc.
The things I have seen work:
* Solve the problems other developers are unwilling or incapable of solving.
* Create helpful (and portable) tools
* Learn analytics and increase your communication skills
* Be helpful
* Solve the problems other developers are unwilling or incapable of solving.
* Create helpful (and portable) tools
* Learn analytics and increase your communication skills
* Be helpful
The "next level" is for you to define. For me, it was communication and design. For you it might be a new language or simply better test coverage.
I would say that getting the right internship will make a huge difference.
In 2009 before I went to university I was still living at home, splitting firewood in the middle of nowhere in New Brunswick, Canada to make a bit of extra money. This turned out to be an activity with an effective wage of about $10/hour.
In 2012 I was interning at NVIDIA in Santa Clara. Interns get lots of special treatment to indoctrinate you into the company, so I got to meet the CEO and he invited all the interns over to his house. Of course, he would probably never remember me, but I can't think of many other ways to move so quickly into a place where you could actually have some influence.
In 2009 before I went to university I was still living at home, splitting firewood in the middle of nowhere in New Brunswick, Canada to make a bit of extra money. This turned out to be an activity with an effective wage of about $10/hour.
In 2012 I was interning at NVIDIA in Santa Clara. Interns get lots of special treatment to indoctrinate you into the company, so I got to meet the CEO and he invited all the interns over to his house. Of course, he would probably never remember me, but I can't think of many other ways to move so quickly into a place where you could actually have some influence.
talk to your manager or find a mentor. what's needed to move up can vary based on where you work. for more general advice, or if you are self employed, there's a lot of other good comments here.
Written communication. Writing concise, direct, accurate, and easy to read emails/jiras/etc.
If you're a dev or not this holds true. Your boss and your bosses boss are busy. Help them understand what you do by writing your thoughts clearly.
The other is finishing. Work on things you can finish. Don't aim to rebuild Rome in an afternoon. Doing the dirty work to take something from 90% to 100% is HARD. Finishing things adds so much value and for some reason people are bad at it.
If you're a dev or not this holds true. Your boss and your bosses boss are busy. Help them understand what you do by writing your thoughts clearly.
The other is finishing. Work on things you can finish. Don't aim to rebuild Rome in an afternoon. Doing the dirty work to take something from 90% to 100% is HARD. Finishing things adds so much value and for some reason people are bad at it.
Stop looking for the 'one thing'
Stop looking for 'one thing', or One True Way.
Find a mentor.
Read a shitton of open source related to your area and try to apply it to your project.
Having the buck stop with you. With nowhere else to turn, you have to step up pretty fast. It forces you to own your decisions and not run to more senior people to help with your problems.
Learn how the business works.
I think this should be higher in this stack of random things because that's just one of those things that makes someone seem naive. Ok, you are junior person in a company- can you explain how your paycheck is funded? Can you see why what you are working right now directly benefits your business? Why is this area of the system more critical than that area of the system? What is the customer perspective on whether this works or not and will it affect the money?
Much like the other mention of communication this is just one of those things you learn on the job and outside of school/solo work. This knowledge also helps guide your decision making/architecture work with dealing with a system over time as well as general decision making/prioritization.
Much like the other mention of communication this is just one of those things you learn on the job and outside of school/solo work. This knowledge also helps guide your decision making/architecture work with dealing with a system over time as well as general decision making/prioritization.
To master a lot of the most "hard core" programming concepts, dive into parsers and compilers. It will give you a perspective and generality that will permeate the rest of your career. It gives you arguably the most high-level perspective on all things related to programming and the paradigms therein.
Get a mentor. This takes a bit of luck to find a mentor (or great boss) but the rewards are massive. They'll teach you what's relevant to study/learn, they'll teach you what to focus on to get the most return, they'll be a back stop to technical questions, they'll be endless knowledge, they'll be a role model.
Hard Work and Discipline
Think and talk about the functional problem instead of thinking and talking about a specific technical solution.
And the next level above that: think and talk about the business problem the proposed functionality is intended to address.
Making the distinction between requirements, functional design and technical design is very helpful, but in many places this has been obscured and rendered difficult by bureaucracy and process.
And the next level above that: think and talk about the business problem the proposed functionality is intended to address.
Making the distinction between requirements, functional design and technical design is very helpful, but in many places this has been obscured and rendered difficult by bureaucracy and process.
There's no one thing that's going to be the line which, after crossing, you can safely stop calling yourself junior. Indeed, I've worked with many "senior" developers who I would have considered junior outside their area(s) of expertise (and I myself fall into this category as well!)
When I'm conducting interviews and looking for hints that someone might be on the verge of "levelling up", I look for qualities that indicate someone has stopped following a preset path and is instead able to do their own pathfinding. That is, given a direction and a general set of guidelines, how deep are they able to go in order to solve this problem? If I tell you, "Hey, we want to add file uploads to this UI" in a Ruby project, do you:
A) immediately go searching for a gem to handle this?
B) Look for an AWS interface gem?
C) Look at S3's HTTP docs and write their own class for handling?
D) Stop and ask if we want to host the files ourselves or using a storage API of some sort?
Each of those may be the right answer. A is what I would expect a junior (and likely most others) to do, and its a defensible choice in that file uploads are likely not interesting enough to spend much time on. B) is what I would expect from someone who knows that storage to S3 is pretty easy in most libraries, and therefore it may not be worth the dependency of something like Carrierwave, electing instead to write a thin wrapper around the interface (and whether they use it directly in application code, or write the wrapper, is an excellent way to discern whether they're just below or just above the line between junior and mid-level). If they're coming from a different platform background though, they might just be unaware of something like Carrierwave/Dragonfly/etc. Option C indicates that they're probably pretty comfortable getting deep into a problem, though perhaps not always making the best choices about where to spend time (but you get a pass if this is an interview setting, its really hard to know as a candidate what the other side of the table is looking for.) Going with option D often indicates the confidence to push back on requirements and make sure you're writing the right code, not just what the ticket or client asks for.
The thing is, none of those in isolation is going to definitely indicate that someone is a junior or more advanced. They're all just pieces of evidence and have to be taken with other points of evidence to determine the answer to that question.
Other things I'd probably try to focus on if I were trying to level up:
* Know your tools. I don't care whether you use vi/vim, emacs, spacemacs, Sublime, atom, intellij or one of its brethren, or even textmate—know how to use it effectively to navigate your project and handle your top ten tasks like finding the implementation of a class or running your tests.
* Know your CLI. I don't care that you know every flag to every possible command in the terminal. but realize that an IDE is usually just a layer over a lot of CLI tools that you should be able to handle in their native environment.
* know how to read a stack trace effectively to find the root cause of an error quickly.
* get good with taking constructive criticism. Humility is an important attribute in any team member.
* Don't fall into the trap of thinking you know one tenth of what you believe you do. Don't think in absolutes, and don't argue with every potentially incorrect statement someone makes.
* ask questions more than make statements. Whether its "Can you help me understand why you do that this way?" or "Why is the customer asking for this feature?" it will serve you well throughout your career.
When I'm conducting interviews and looking for hints that someone might be on the verge of "levelling up", I look for qualities that indicate someone has stopped following a preset path and is instead able to do their own pathfinding. That is, given a direction and a general set of guidelines, how deep are they able to go in order to solve this problem? If I tell you, "Hey, we want to add file uploads to this UI" in a Ruby project, do you:
A) immediately go searching for a gem to handle this?
B) Look for an AWS interface gem?
C) Look at S3's HTTP docs and write their own class for handling?
D) Stop and ask if we want to host the files ourselves or using a storage API of some sort?
Each of those may be the right answer. A is what I would expect a junior (and likely most others) to do, and its a defensible choice in that file uploads are likely not interesting enough to spend much time on. B) is what I would expect from someone who knows that storage to S3 is pretty easy in most libraries, and therefore it may not be worth the dependency of something like Carrierwave, electing instead to write a thin wrapper around the interface (and whether they use it directly in application code, or write the wrapper, is an excellent way to discern whether they're just below or just above the line between junior and mid-level). If they're coming from a different platform background though, they might just be unaware of something like Carrierwave/Dragonfly/etc. Option C indicates that they're probably pretty comfortable getting deep into a problem, though perhaps not always making the best choices about where to spend time (but you get a pass if this is an interview setting, its really hard to know as a candidate what the other side of the table is looking for.) Going with option D often indicates the confidence to push back on requirements and make sure you're writing the right code, not just what the ticket or client asks for.
The thing is, none of those in isolation is going to definitely indicate that someone is a junior or more advanced. They're all just pieces of evidence and have to be taken with other points of evidence to determine the answer to that question.
Other things I'd probably try to focus on if I were trying to level up:
* Know your tools. I don't care whether you use vi/vim, emacs, spacemacs, Sublime, atom, intellij or one of its brethren, or even textmate—know how to use it effectively to navigate your project and handle your top ten tasks like finding the implementation of a class or running your tests.
* Know your CLI. I don't care that you know every flag to every possible command in the terminal. but realize that an IDE is usually just a layer over a lot of CLI tools that you should be able to handle in their native environment.
* know how to read a stack trace effectively to find the root cause of an error quickly.
* get good with taking constructive criticism. Humility is an important attribute in any team member.
* Don't fall into the trap of thinking you know one tenth of what you believe you do. Don't think in absolutes, and don't argue with every potentially incorrect statement someone makes.
* ask questions more than make statements. Whether its "Can you help me understand why you do that this way?" or "Why is the customer asking for this feature?" it will serve you well throughout your career.
Experience.
1) Be helpful. Colleague beating her forehead against her desk debugging something? Go help. Account manager running into a bug? Go help. Sales team encountering pushback from a potential customer? Go help. You'll learn a ton.
2) Learn why you're building something. Not just the technical 'why', but also the business 'why'. Yes, you should understand why you're using RabbitMQ over Redis. You should also try to understand the business case that you're solving – in as much depth as you can get. The stronger you align with what your business needs, the more valuable you become, and the harder problems you will be solving, an the more you'll have the opportunity to learn.
2) Learn why you're building something. Not just the technical 'why', but also the business 'why'. Yes, you should understand why you're using RabbitMQ over Redis. You should also try to understand the business case that you're solving – in as much depth as you can get. The stronger you align with what your business needs, the more valuable you become, and the harder problems you will be solving, an the more you'll have the opportunity to learn.
There are many things you can do, and not really "one" silver bullet, but I feel the most important are "soft-skills" and a hyper-focus on learning. You asked for one, but the two of them are so deeply connected, I feel they warrant being included together.
Communication/soft-skills has already been mentioned so I'll leave it with the simple "At the end of the day, regardless of how smart you are, if you cannot work well with others and you're not the sole employee/owner, your value is very limited".
The biggest problem I've found being a software developer is exposed by this phenomenon referred to as Imposter Syndrom[0]. In a lot of fields, there are good ways to measure yourself and your skills against others. In software development, it's a difficult thing to measure. You can become an "expert" in the core language you write in -- understanding the common patterns, standard libraries, and common features -- and no matter how much your abilities increase, what you know is far less than what you don't know.
Even today, with resources like StackOverflow, open-source material and source repositories with endless amounts of code available, learning corners of your specialty is hard. Your resource may be "out-of-date" (which happens within weeks, rather than months/years) or might be so specialized that there's just nothing out there[1]. Because of Imposter Syndrom, your developers are not quick to point out their weaknesses, but knowing the strengths/weaknesses of your coworkers helps you to be effective and to know who to tap when you get stuck. Unlike "that person in the forum", they have a vested interest in making you better -- you'll reduce their workload the more effective you become. Provided you're good at establishing relationships/friendships with others, they'll actively help you to become better and there's no better way to learn than one-on-one with someone who has the skills you lack. Knowing their weaknesses allows you to better focus your study on areas that the team has gaps (tip: offer up your own deficiencies and others will open up about theirs).
A lot also depends on what corner of software development you're focused on. If you're focused on web front-end development, you have a much easier time learning what you need to learn, and more jobs available to shine in, but you also have a huge amount of competition and a greater distance between Junior and Senior. In a highly specialized area -- mine was Skype for Business development -- you have fewer job options, almost no resources but a much smaller distance between Junior and Senior since simply having experience in one of the APIs already puts you near the middle. At first, I was tempted to say that being in the latter category is helpful, but having done it and reflecting on how painful it is when you run into a problem and have, literally, nobody to turn to for help[2], I can't say that I recommend it. Picking an area of focus that is somewhere in the middle might be a good idea. :o)
On learning, figure out what techniques are most effective for you. I don't do well in lectures, and I don't have the patience for video tutorials. I took a class about 20 years ago on effective book study (it was called "speed reading" at the time, but has nothing to do with these gimmicky techniques taught by apps, today). I learned how to skim/scan material and take effective notes while doing so, allowing me to consume huge books in hours, and "read" those books for information several times over a period of a week/month. I felt like I had a "super power" and exercised this ability to the tune of about 6-10 large volumes per year. When I need to learn something, I look for a good, thick, book on the subject, set a goal for completion and relentlessly pour myself into it. For programming, I know this requires me finding a personal, useful, project to build, an "instructional book" and a "reference book". Give me those three things and the language, framework or pattern in question will be cemented in a way that allows me to use it at a practical level.
[0] https://www.hanselman.com/blog/ImAPhonyAreYou.aspx
[1] My area of focus until very recently was developing software for Skype for Business using some of the (very excellent) APIs provided by Microsoft. Unfortunately, the number of people who are doing professional development in this software is small due to its target audience being enterprises. You just don't have a large number of hobbyists writing libraries on the weekends. The primary API I used to develop in, UCMA, had one half-chapter in one large book written in 2007, none of which is helpful to new developers due to it being wildly out of date. The documentation for this API is mostly "Undocumentation", and I've encountered very few APIs that have as many sharp edges, parts that don't work as you'd intuitively expect or simply don't work in any way resembling the documentation.
[2] I can't tell you how many times I've googled a problem and ran into solutions where the answer was provided by a person I worked with that I could have tapped on the shoulder. Or the two times I googled something, saw the answer (in one case, slightly disagreeing with the approach) only to discover that the person who wrote it ... was me. Just goes to show that anything in software that you've written six months ago might as well have been written by someone else.
Communication/soft-skills has already been mentioned so I'll leave it with the simple "At the end of the day, regardless of how smart you are, if you cannot work well with others and you're not the sole employee/owner, your value is very limited".
The biggest problem I've found being a software developer is exposed by this phenomenon referred to as Imposter Syndrom[0]. In a lot of fields, there are good ways to measure yourself and your skills against others. In software development, it's a difficult thing to measure. You can become an "expert" in the core language you write in -- understanding the common patterns, standard libraries, and common features -- and no matter how much your abilities increase, what you know is far less than what you don't know.
Even today, with resources like StackOverflow, open-source material and source repositories with endless amounts of code available, learning corners of your specialty is hard. Your resource may be "out-of-date" (which happens within weeks, rather than months/years) or might be so specialized that there's just nothing out there[1]. Because of Imposter Syndrom, your developers are not quick to point out their weaknesses, but knowing the strengths/weaknesses of your coworkers helps you to be effective and to know who to tap when you get stuck. Unlike "that person in the forum", they have a vested interest in making you better -- you'll reduce their workload the more effective you become. Provided you're good at establishing relationships/friendships with others, they'll actively help you to become better and there's no better way to learn than one-on-one with someone who has the skills you lack. Knowing their weaknesses allows you to better focus your study on areas that the team has gaps (tip: offer up your own deficiencies and others will open up about theirs).
A lot also depends on what corner of software development you're focused on. If you're focused on web front-end development, you have a much easier time learning what you need to learn, and more jobs available to shine in, but you also have a huge amount of competition and a greater distance between Junior and Senior. In a highly specialized area -- mine was Skype for Business development -- you have fewer job options, almost no resources but a much smaller distance between Junior and Senior since simply having experience in one of the APIs already puts you near the middle. At first, I was tempted to say that being in the latter category is helpful, but having done it and reflecting on how painful it is when you run into a problem and have, literally, nobody to turn to for help[2], I can't say that I recommend it. Picking an area of focus that is somewhere in the middle might be a good idea. :o)
On learning, figure out what techniques are most effective for you. I don't do well in lectures, and I don't have the patience for video tutorials. I took a class about 20 years ago on effective book study (it was called "speed reading" at the time, but has nothing to do with these gimmicky techniques taught by apps, today). I learned how to skim/scan material and take effective notes while doing so, allowing me to consume huge books in hours, and "read" those books for information several times over a period of a week/month. I felt like I had a "super power" and exercised this ability to the tune of about 6-10 large volumes per year. When I need to learn something, I look for a good, thick, book on the subject, set a goal for completion and relentlessly pour myself into it. For programming, I know this requires me finding a personal, useful, project to build, an "instructional book" and a "reference book". Give me those three things and the language, framework or pattern in question will be cemented in a way that allows me to use it at a practical level.
[0] https://www.hanselman.com/blog/ImAPhonyAreYou.aspx
[1] My area of focus until very recently was developing software for Skype for Business using some of the (very excellent) APIs provided by Microsoft. Unfortunately, the number of people who are doing professional development in this software is small due to its target audience being enterprises. You just don't have a large number of hobbyists writing libraries on the weekends. The primary API I used to develop in, UCMA, had one half-chapter in one large book written in 2007, none of which is helpful to new developers due to it being wildly out of date. The documentation for this API is mostly "Undocumentation", and I've encountered very few APIs that have as many sharp edges, parts that don't work as you'd intuitively expect or simply don't work in any way resembling the documentation.
[2] I can't tell you how many times I've googled a problem and ran into solutions where the answer was provided by a person I worked with that I could have tapped on the shoulder. Or the two times I googled something, saw the answer (in one case, slightly disagreeing with the approach) only to discover that the person who wrote it ... was me. Just goes to show that anything in software that you've written six months ago might as well have been written by someone else.
Software is the manifestation of a solution to a problem. Define the problem which needs to be solved.
Probably the upside down t-shaped graph of expertise, where you know a lot about one topic and a little about everything else. I believe this happens sort of naturally if you just work where you're needed because you'll get pigeonholed as the person who can do X whenever it needs to be done, then you can branch out when X is finished. I'm not sure because I'm still pretty junior myself.
You get a similar effect from repeatedly reading hn, because you'll read articles on topics you know about and then branch out when you're bored of it.
You get a similar effect from repeatedly reading hn, because you'll read articles on topics you know about and then branch out when you're bored of it.
I don't think it happens automatically. It requires some natural curiosity. Some people just work on the assignments as they are given to them (which is not a bad thing per-se, just different from the regularly-hyped rockstar or ninja programmer).
Work in a startup and try to do a little bit of everything (code, devops, marketing, selling). Be really good at 2 of those at least and just hit the ground running.
You might not know how to do something, but ask to do it anyways and learn it on the go. Big corporations will not give you that kind of opportunity so you have to find a startup or create one yourself.
Code and blog a lot and put everything on GitHub and try to get people to star your projects and follow you. Learn to design, architect and structure your code for large systems.
You might not know how to do something, but ask to do it anyways and learn it on the go. Big corporations will not give you that kind of opportunity so you have to find a startup or create one yourself.
Code and blog a lot and put everything on GitHub and try to get people to star your projects and follow you. Learn to design, architect and structure your code for large systems.
* Being able to design a small project from scratch and execute it to completion.
* Knowing when to ask for help and related time management skills: (https://codewithoutrules.com/2016/03/02/asking-for-help/).