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!"
Also related: https://schloss.quora.com/Design-doesnt-deserve-a-seat-at-th...
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)
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.
Obviously it takes a lot of legwork on your own part, but having the guidance helps a whole lot.
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.
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
Also don't deliver buggy code.
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.
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.
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.
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.
Anyway, assuming programming: https://github.com/braydie/HowToBeAProgrammer
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.
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 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.
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.
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.
* 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/).
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.
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.
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.
* 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
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.
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.