Don't stress about not being good enough when you see other people's work. People show off their end result and not the hundreds of broken iterations it took to get there. You can build exactly the same stuff with a bit of effort, learning and time.
Corollary: if someone posts "my first X" to a big public site like reddit or HN, it is almost certainly not literally their first X; it's just the first one they felt comfortable enough to exhibit publicly.
Start off by going deep, not wide. You'll pick up other languages and technologies over time. Pick a stack that appeals to you and focus on it for a while, learning its idioms and best practices and improving your development fundamentals.
Never, ever, stop learning. Don't feel too bad if you can't find time for a personal project like everybody else seems to have. Just make sure you are up-to-date with the hectic changes in the programming world.
Every single time you're on HN and you're reading an article about Kubernetes while you're just a frontend web developer expands your horizons and advances your career.
And when you know something about most things, with some specialisation, go freelance and expand your skillset and knowledge further.
The moment you stop learning is the moment your career crystallises and dies.
Don't overestimate reading an article about Kubernetes. It creates awareness of the concept and what it could offer, but that is not the same as going wide, it is too superficial.
I agree to this, but in the sense that you should dig deep and understand how something works under the hood.
For example, ElasticSearch is “fast”, but what makes it so? What trade offs were made to make it “fast”?
You may start seeing patterns on how good/bad tech stack are built (aka the meta), and those meta would help you a lot down the road in knowing what type of toolset you can use, common type of problems a given architecture would exposed to.
Agreed. Do something really deeply and for a long time. Getting started with a tech is always easy but only through several release cycles you learn the real difficulties of programming which are making changes to an old codebase, when to refactor, training new people on the system, deciding on adding new tech.
But then don't get attached to this but be willing to move to other things if they make better sense.
In summary try to develop good judgement based on real world experience.
Focus on a niche and specialize more than “software”. As a junior you have some time to figure it out (but don’t take too long). Software is everything these days, so if you can focus on a subfield you’ll maximize your future earning potential and lifestyle. It’ll also help you stay technical well into your career.
To do this, keep your eyes open for opportunities to go deep into something interesting at your job and be the company expert on that topic. This is a nugget of a personal brand. Then take this and expand on it outside your first job. Blog about it. Speak about it. Create open source about it. Find the next job that hires you for these specialized skills. Rinse repeat...
Worst case is you can still switch, or go back to just “software developer”
Learn to be useful to the organisation where you're working.
Don't just be about upping your own skills and stuff. Being valuable to the person who's employing you is what makes your progress in your career.
Learn to be a professional.
Basic things like showing up on time, being a good communicator etc.
>Being valuable to the person who's employing you is what makes your progress in your career.
More importantly learn how to be recognized as valuable. It's better to appear valuable without actually being valuable than being valuable but not recognized, and often you don't even have a good idea what's valuable in the bigger picture on your own so accepting others valuation can help you from being stuck in your bubble.
It looks like this comment is being downvoted because it appears to endorse being deceptive.
I’d like to chime in and second the sentiment in slightly different terms: value is not inherently visible. You can waste a lot of time contributing significant invisible value to a company with no recognition or reward. On the other hand, you can provide a small amount of value and receive significant recognition just by making that value as visible as possible.
If you’re looking to have your value recognized, you need to commit energy to making it visible. This means different things in different roles and organizations, but it’s a critical skill to develop.
And it doesn’t just apply in business relationships! Learn to make your value visible; it ensures the energy you put into anything is appropriately acknowledged.
If you don't have the personality to market yourself keep yourself in a position where you contribution is obvious.
Working on a self directed project that makes tools for other developers can be fun, but if you can't sell the value of that work you should stay on a team that generates obvious features for paying customers. (which is to say work on projects where marketing will sell your work, this indirectly outsourcing making yourself visible to marketing)
All I'm saying is that most of what you're trying to accomplish relates to getting recognition and that's not guaranteed by simply doing the work - sometimes it's not even predicated on it. This is something that isn't obvious to new and idealistic juniors.
OTOH maybe that's the way it should be - first you work your ass off and get real skills then you learn how to sell but have the skill to back it up.
Also a LOT of people fall in to the trap of thinking just because they perceive something as valuable that it's actually valuable to the employer - zealous juniors learning best practices without knowing how to put them in context wasting time and effort and getting frustrated for not getting recognized even though they "are right" .
Start building your career so you have job security now. This means doing things to eventually move into management or doing projects/blogs/postcasts so that you stand out.
When resumes come across someones desk being a generic developer is not going to help, and it gets worse as you get older. Having something that you can show off even if its just a collection of blog posts about how you built a simple CLI tool using Nim will make you stand out.
Work on your soft skills. Being able to communicate and get your ideas across is more important then being able write the best code in any organisation. It will make you stand out. Learn public speaking and show what you have done. Be your own champion because its rare for someone to do that for you.
Lastly, learn some new technology and write posts about it. You will become the expert in it if you do this at the right time and frequently. This will open up new opportunities.
Read the clean code book by Rob Martin and the head first design patterns book. Both are musts for software engineers and Amazon top sellers for developers. Other than that be like a sponge and learn transferable skills in one or two mainstream languages, you can't go wrong with Java, c#, sql and angular.
Do read those books, but don't take them as gospel, and don't be afraid to use your own judgement.
Both have some flaws and highly subjective advice in them, and if something doesn't seem to add up, it's very possible that there's a better way. Try things out and see how they fit.
Don't chase money, only focus on doing hard things that scare you at first (think: at the limit of what you're capable of), then change when you're done learning. Iterate for > 10 years.
Always work with people smarter than you. Ethics are important. Don't stop trying to improve. There is money to be made in every IT area, follow what you like and you wont be poor or unhappy. Respect others' work no matter how crappy, specially open source/free work.
Good enough is better than perfect. It is also way better than 'not yet done'. Always have targets in mind. Even green field explorative projects should have targets. Good engineers ship.
Abstraction and encapsulation is overrated. Premature generalization is the root of all evil.
I like your way of thinking. A former team lead of mine used to say "Don't let perfect be the enemy of good". As a perfectionist, after a few hard lessons I couldn't agree more.
Don't decide too early. If you can postpone a decision that doesn't delay your overall work, then postpone it. You may have more data later to take the right decision.
Don't optimize too early (premature optimization). Always try first the simpler approach, you will finish earlier, get simpler code and find out that some minor optimizations or not at all are needed. You should always check this with real world data / scenarios.
I'm confused. Are you saying the CTO and lead developer overvalue your skills or that they too think others overvalue your skills (as in they don't think as highly of your skills)?
Are you sure it needs to be "cured"? Lately I have been thinking that it's a blessing in disguise; a painful -but effective- motivator to improve and seek out new skills and more knowledge.
Yes, it comes with a side of depression, and that really sucks, but I've found if I'm deep in some tech I don't know, it doesn't seem to affect me nearly as much.
Could it be jut us getting restless? The feeling we haven't learned anything new or faced any new challenges lately?
Nah, as you say it is a blessing. And I wouldn't trust anyone who thinks they're underrated or they know "enough" about anything.
> Could it be jut us getting restless? The feeling we haven't learned anything new or faced any new challenges lately?
I bet one could win a Nobel prize for breakthrough research and still feel like a fraud. "Ugh, did those idiots really give _me_ a Nobel prize for this? What were they thinking?" :)
Don't say no to work just because it is not using the stack/vertical that you want to be in. Rejecting offers and jobs just because it is not in your preferred tech stack/department/vertical is the worst thing you can do for your career. I learnt this the hard way. Make sure you don't.
On the flip side, if you have tried a stack, and after half a year or so still don't like working with it, it's no shame to look for something else to work on that you enjoy more.
Don't be scared of going into reading source code of libraries/frameworks you are using to understand how things work.
The code will often be simpler than you think and allow you have a better, deeper understanding of how things work and empower you incredibly.
Also don't be scared if you arrive at some source code and can't make head nor tail of it. Given time and enough attempts you'll start to be able to find the info you need, but for some projects it'll never happen. :)
Develop good habits: physical conditioning, mental conditioning, avoiding drugs and alcohol, etc. If you want to be doing this kind of work for the long haul, protect your body and mind. In your 20s, you can be a couch potato, etc, and probably do this job. In your 50s? The proportion of people still doing this job who don't take care of themselves is much smaller.
I would add on and say: don't underestimate the physical toll of having a job based on typing at a desk. Your back, hands, wrists, arms, hips, and probably more can take a big toll directly from performing your job. If you're not careful to avoid stress, burnout, etc, then you're also directly or indirectly inviting huge risk to your heart, weight, mental health, and more.
Drink lots of water. Go to the bathroom. Have little walks or stretches in the office, at least at your desk or in your chair. Go for a walk after dinner. Do some light exercises at home if you can't walk at home. Sleep, sleep, sleep.
If you can, don't hesitate to ask senior dev for help (but only once you've done your own research). In that case, knowing how to explain what's the problem, in the context of what you are trying to do (the context is important because of the XY problem). Communication with non-dev and person outside your project is important, usually those person will either control the budget or be users and stakeholder. Admit your mistakes, especially when they affect other persons.
try to be autosufficient. if you have a problem, try to fix it yourself. try googling, reading source codes if you have to. it's very annoying when people come to me with questions that could have been resolved by doing 5 minutes of research online.
Some developers have n years of experience, others have the same year of experience repeated n times.
The latter happens when a developer becomes too comfortable with their knowledge and stops learning, or when they emphasize development speed over learning.
If you want to be an expert, cargo cult needs to stop with you. Don't blindly imitate what others do, try to understand how things work and how they can work better.
Unless you are in academia/research, your job is not to produce software - it is to solve customer problems, add customer value, and help your team-mates and wider colleagues. You should be able to trust your colleagues on the marketing and product side of things, and while you should be honest with them about tech limitations/requirements, you need to be able to work with them to deliver product.
But to have a career you also need to pad your resume with the right buzzwords. Just solving business problems without considering your resume is good for the business but will make it very difficult to advance your career if you are an engineer.
1) If you're not a native English speaker, always improve your English.
2) Start your open source side project and work on it in your spare time.
3) Improve your skills by reading books and attending online courses.
4) Change your job/project every year.
re: 4) - if your CV has a new job on it every year, I would be much less inclined to interview/hire you. After all, 1 year in is when a developer really becomes valuable to an organization.
This quote is so silly, and misused. It’s like one of those facts about Einstein that you’ll see on Facebook.
For one, in this context, a junior developer will rarely be the smartest person in the room. So it’s really terrible advice for the context.
I think it’s really terrible advice in general though, the places I’ve learned the most is exactly when I’m the smartest person in the room, doing stuff like mentoring or teaching.
In fact I do part time work as an external examiner at IT educations in my country, exactly because they teach me a lot. I’m almost always the smartest person in those rooms, but by evaluating i relearn/refresh things that I haven’t touched in a while.
Aside from that, you’re almost never in a room where there isn’t an opportunity to learn. Maybe you’re the best programmer in the room, maybe you’re the best architect, but you’re very rarely the best at everything, and the modern workplaces thrives the most from teams, in which everyone is the best at something, because they become more than their individual sums by cooperating.
In a non-technical environment, it is very easy for a junior developer to end up the smartest person in the room as far as tech is concerned. Think meetings with SMEs, PMs, or Sales.
The statement is if you are "the smartest person in the room", not "the smartest person in the room in one narrow area". If SMEs, PMs and Sales people aren't smarter than you in some other areas, then you are somewhere with incompetent SMEs, PMs and Sales people.
458 comments
[ 2.2 ms ] story [ 222 ms ] thread(At least, that's what I tell myself...)
Read books/practice software design patterns and learn how to write tests. (Unit, integration, end to end)
I'd second this. "Junior developer" is generally just used to pay developers less.
Never, ever, stop learning. Don't feel too bad if you can't find time for a personal project like everybody else seems to have. Just make sure you are up-to-date with the hectic changes in the programming world.
Every single time you're on HN and you're reading an article about Kubernetes while you're just a frontend web developer expands your horizons and advances your career.
And when you know something about most things, with some specialisation, go freelance and expand your skillset and knowledge further.
The moment you stop learning is the moment your career crystallises and dies.
For example, ElasticSearch is “fast”, but what makes it so? What trade offs were made to make it “fast”?
You may start seeing patterns on how good/bad tech stack are built (aka the meta), and those meta would help you a lot down the road in knowing what type of toolset you can use, common type of problems a given architecture would exposed to.
In summary try to develop good judgement based on real world experience.
To do this, keep your eyes open for opportunities to go deep into something interesting at your job and be the company expert on that topic. This is a nugget of a personal brand. Then take this and expand on it outside your first job. Blog about it. Speak about it. Create open source about it. Find the next job that hires you for these specialized skills. Rinse repeat...
Worst case is you can still switch, or go back to just “software developer”
Learn to be a professional. Basic things like showing up on time, being a good communicator etc.
More importantly learn how to be recognized as valuable. It's better to appear valuable without actually being valuable than being valuable but not recognized, and often you don't even have a good idea what's valuable in the bigger picture on your own so accepting others valuation can help you from being stuck in your bubble.
I’d like to chime in and second the sentiment in slightly different terms: value is not inherently visible. You can waste a lot of time contributing significant invisible value to a company with no recognition or reward. On the other hand, you can provide a small amount of value and receive significant recognition just by making that value as visible as possible.
If you’re looking to have your value recognized, you need to commit energy to making it visible. This means different things in different roles and organizations, but it’s a critical skill to develop.
And it doesn’t just apply in business relationships! Learn to make your value visible; it ensures the energy you put into anything is appropriately acknowledged.
Working on a self directed project that makes tools for other developers can be fun, but if you can't sell the value of that work you should stay on a team that generates obvious features for paying customers. (which is to say work on projects where marketing will sell your work, this indirectly outsourcing making yourself visible to marketing)
OTOH maybe that's the way it should be - first you work your ass off and get real skills then you learn how to sell but have the skill to back it up.
Also a LOT of people fall in to the trap of thinking just because they perceive something as valuable that it's actually valuable to the employer - zealous juniors learning best practices without knowing how to put them in context wasting time and effort and getting frustrated for not getting recognized even though they "are right" .
When resumes come across someones desk being a generic developer is not going to help, and it gets worse as you get older. Having something that you can show off even if its just a collection of blog posts about how you built a simple CLI tool using Nim will make you stand out.
Work on your soft skills. Being able to communicate and get your ideas across is more important then being able write the best code in any organisation. It will make you stand out. Learn public speaking and show what you have done. Be your own champion because its rare for someone to do that for you.
Lastly, learn some new technology and write posts about it. You will become the expert in it if you do this at the right time and frequently. This will open up new opportunities.
Both have some flaws and highly subjective advice in them, and if something doesn't seem to add up, it's very possible that there's a better way. Try things out and see how they fit.
I’m not an algorithmic genius don’t get me wrong, that part doesn’t appeal as much to me.
> Don't stop trying to improve.
can't ever be overstated.
Abstraction and encapsulation is overrated. Premature generalization is the root of all evil.
Knowledge is no substitute for experience.
You cannot google what you do not know it exists.
Don't decide too early. If you can postpone a decision that doesn't delay your overall work, then postpone it. You may have more data later to take the right decision.
Don't optimize too early (premature optimization). Always try first the simpler approach, you will finish earlier, get simpler code and find out that some minor optimizations or not at all are needed. You should always check this with real world data / scenarios.
I have 13 years of experience, CTO and lead developer at my company and a part of me always thinks people are way overvaluing my skills.
You just learn to ignore it, but it never goes away.
Yes, it comes with a side of depression, and that really sucks, but I've found if I'm deep in some tech I don't know, it doesn't seem to affect me nearly as much.
Could it be jut us getting restless? The feeling we haven't learned anything new or faced any new challenges lately?
Nah, as you say it is a blessing. And I wouldn't trust anyone who thinks they're underrated or they know "enough" about anything.
> Could it be jut us getting restless? The feeling we haven't learned anything new or faced any new challenges lately?
I bet one could win a Nobel prize for breakthrough research and still feel like a fraud. "Ugh, did those idiots really give _me_ a Nobel prize for this? What were they thinking?" :)
Drink lots of water. Go to the bathroom. Have little walks or stretches in the office, at least at your desk or in your chair. Go for a walk after dinner. Do some light exercises at home if you can't walk at home. Sleep, sleep, sleep.
The latter happens when a developer becomes too comfortable with their knowledge and stops learning, or when they emphasize development speed over learning.
If you want to be an expert, cargo cult needs to stop with you. Don't blindly imitate what others do, try to understand how things work and how they can work better.
For one, in this context, a junior developer will rarely be the smartest person in the room. So it’s really terrible advice for the context.
I think it’s really terrible advice in general though, the places I’ve learned the most is exactly when I’m the smartest person in the room, doing stuff like mentoring or teaching.
In fact I do part time work as an external examiner at IT educations in my country, exactly because they teach me a lot. I’m almost always the smartest person in those rooms, but by evaluating i relearn/refresh things that I haven’t touched in a while.
Aside from that, you’re almost never in a room where there isn’t an opportunity to learn. Maybe you’re the best programmer in the room, maybe you’re the best architect, but you’re very rarely the best at everything, and the modern workplaces thrives the most from teams, in which everyone is the best at something, because they become more than their individual sums by cooperating.
Also just because your the teacher doesn't mean your smarter than all your students you may know more.