100% of the juniors (and an awful lot of seniors) I've ever trained simply ignore those and then come ask for help debugging.
99% of the time, the explanation for their problem is literally the first line of the stack trace/error message/whatever is red on their screen.
If you successfully adopt the mindset of "whatever the computer is telling is true from the computer point of view, so I'd better make sure I've read it" instead of "Anyway, I'll try something else and run again", you'll debug 10 times faster. And since debugging is a good part of the job, you'll be a lot more productive.
In a surprising number of coding interviews that I've conducted, I've seen a candidate write an incorrect solution that generates an exception and then attempt to figure out the error almost on first principles, rather than actually reading the exception carefully and thinking about what coding errors could have caused it to happen. The exception message is a _huge_ hint!
It's a red flag to see someone try to debug without paying attention to it. Conversely it's very positive to see someone encounter one and then think carefully about it. Writing an incorrect solution but then testing it out and showing the ability to debug and fix it systematically and expediently is no worse than getting it right on the first try, in my book.
I mean, how could anyone ever learn to program well enough to get a job as a professional programmer without knowing to do that?
Likewise, I think adopting a "how can I create a stack trace/error message" mindset is incredibly important.
Can you add a breakpoint to a certain piece of code? Could you add a try/catch statement somewhere to catch the error?
Far too often good engineers do not have an "active" mindset in hunting for stack traces/error messages, instead, they wait for them to fall like manna from heaven.
My answer was that I looked at the error message and then, if it was available, scanned the backtrace to figure out which files/method calls were involved. Otherwise (particularly with JS), I set up some breakpoints in the browser to help visualise things better.
I've come across plenty of senior developers who ignore what the machine says. The thing is, most bugs aren't solved through intuition, so approaching the problem as if your gut feeling is completely accurate is going to turn a 10 minute debugging session into something that could last a full day. As, in my experience, it once did.
While there is a reason why it did so, those are error messages which are quite hard to understand the first few times they occur to you.
Nevertheless, those lousy error message should be exceptions nowadays, and if you are using decent technologies, the chances are much higher, that you just didn't read the error message not careful enough to understand the problem.
Also, when you have far too many logs, reading in reverse chronological order works most of the time, but not all the time. Generally the last error you are looking at is the error you want to find and fix, but always consider that sometimes an earlier error that seems unrelated can be the reason a later error is even possible.
You'll be glad you did six months down the line, when the exception actually pops up and you instantly know how to reproduce the bug (perhaps because you know the id of the business object involved).
Edit: Also, use understandable text for error messages. Don't go around talking about threads/sockets etc. unless they happen on that abstraction level. The user should see business-level errors, so they know what happened in the business domain and why ("we don't know why, this shouldn't have happened" is a reasonable answer there, too).
Edit 2: I just thought of Git's "plumbing vs porcelain" metaphor. Abusing it slightly: It's much more pleasant to be notified of an error by a red light instead of standing ankle-deep in sewage. I guess that metaphor breaks down a bit, since toilets more often have the latter than the first :)
It's pretty much the same for debugging. I notice the juniors often start to look at where the problem may be. I usually try to first look where it isn't, so I can drill down to where it actually it, in stead of just looking at code and hoping to find what's wrong.
I know you are young and you feel like you're invincible. I know you can pull an all-nighter and work the next day just fine. We have all been in that situation and believe me, it is gonna take a toll at your performance ... and it could even trigger or help you develop some health issues in your life that can sabotage you down the line.
Realize there's only so much progress one can do in the day. Stop before you are absolutely exhausted and passing out, I know it's sounds tempting but please please do not fall into the trap management or more senior people (that were forced to do this too but didn't learn or are "paying it back" now negatively) to wrest that one last drop of energy. After your X allotted time, even if you are still feeling energized, go spend that energy jogging or something! Work a craft, learn to play an instrument.
Risking to toot my own horn, this might be the single best non-technical advice in this thread.
This is definitely the #1 thing to focus on as a junior dev. Start to understand your limits. Listen to your body, become conscientious of your emotional state. One of the best junior developers I had the opportunity to mentor was a 35-40 hour per week developer who consistently day in and day out delivered code. He was dependably consistent and eagerly took advice without ego.
(Totally agree with the advice who have money and relationships though. But none of us start there.)
It's certainly possible to go too far but certainly the path to mastery is paved with many hours of practice, often to the sacrifice of other things. It may not make one feel great to consider you can't become Mozart without deep sacrifices and it doesn't make for advice one feels like giving others. I think the best version of this is probably "work really hard but be aware you have limits, and that sometimes it's important to sacrifice performance and skills development in the name of a balanced life and good health." I don't like framings that could be interpreted to mean if you hustle or don't hustle you'll get the same result, since "there is only so much you can do in a day." Knowing there is a real tradeoff and "know thyself" is a better pov imho.
Try to be consistent and avoid plateauing for long stretches. Consistency will take you far. Maybe you make some sacrifices of other hobbies and uses of time to get some early traction with your skills, but be intentional about doing this and don't put the other things that nourish you on hold forever.
Embrace the beginner's mind that comes easy to you now, remember it so you can cultivate it again more easily when things inevitably feel a little dull or tedious down the road.
Don't follow your passion. Passion will come if your work is meaningful, you are competent and respected for it. So instead work on your competency in whatever field. Leave if the environment will never respect you anyways.
All software problems can be solved if you work on it long enough. Do not give up just because StackOverflow does not have the answer.
A really good question to ask for a task is "How do you know you are done?" It might prompt to clarify requirements. It might prompt you to make things more measurable or testable. It makes you think about implicit things like following code guidelines. It makes you better at estimating time.
Never assume anybody is stupid. Instead, figure out how these intelligent, well-intentioned and experienced people have come to a decision which is stupid now.
Do not just fix symptoms but (at least try to) fix the root problem.
Participate in discussions instead of just listening. If you are wrong, then you learned something at least.
Sit together with experienced developers. Watch how they use their tools.
On that note, don't assume that any particular existing piece of code you find is somehow "blessed". Do assume that everyone, yourself included is a total idiot and capable of writing fallible code, and in every avenue and every respect of life, assume that there _may_ be obvious, ingenious, simple/scalable/efficient/elegant solutions that have been overlooked leaving open possibility of a better way. Never be annoying about it though.
One of the more valuable things I learned in product management is defining what success looks like. It's tempting to just put a product out there/work on something, and think it'll pan out, and you'll know when you're done.
OMG THIS. This is one of the best things anyone can learn.
Ehh, everyone starts at zero and you need passion (or otherwise some form of goal/discipline) to become competent to begin with. Nothing wrong with using passion to follow a goal. Just don't be place all your eggs in one basket; it's not the end of the world if you don't instantly reach your dream goal/salary/life choices.
>Participate in discussions instead of just listening. If you are wrong, then you learned something at least.
I feel being a part of the discourse is especially important and is still something I'm learning to do. There are a few times I wanted to contribute but believed what I had to say was already obvious to everyone else or to at least the people with more expertise and it turned out not being the case. Still, consider choosing your fights and
>Leave if the environment will never respect you anyways.
When you have a conversation with anyone where you think a plan was verbally agreed on, before doing anything your first action is to go back to your desk, write it in an email, send it to them as confirmation and find at least 1 other person, ideally in your reporting line, which you can cc it too.
Because it doesn't take an actively malicious manager to screw you over - it takes literally anyone who suddenly needs to change history to their own seniors for it to fall on you, the underling.
EDIT: And the friendlier or more casual someone is, the more important this becomes.
This is a good advice, glad to see it. While it won't be helping you much to get through your day, it'll count where and when it matters a lot.
You should get confirmation in writing to verify your understanding and protect against a non malicious, honest manager who has a lot of things on his plate and may honestly forget the details of a conversation.
But, if you hope written communication will help you as a CYA move if you have a conflict with your manager and your manager is being purposefully underhanded, that rarely works.
The organizations primary job is to protect the organization. Unless you’re a special snowflake, your manager’s manager or your HR department will always take the side of a manager.
That’s just like getting a PIP. Once you get one, learn from your mistakes and take an honest self assessment - but do it at another job. If you interview while having a job, it’s much easier than trying to interview if you got fired.
This brings us to two very important points:
1. Never delete any email. Only archive. Search does wonders to cover your ass.
2. Never use company email for anything personal because you are never going delete any email and you are not the only person who can search your company email.
Generating a followup email is stating your understanding and interpretation of a verbal conversation. Verbal communication is full of intricacies. Especially when communicating things like priorities.
Why did you spend so much time on that feature and not this one I think is more important?
Why did't you tell me that "minor" feature A was going to mean that this more important feature B IMO was not going to get done in time?
Also, if you have an important decision to make, something that if it goes wrong it would be pretty bad, don't make that decision unilaterally. Partner with your direct report. Get them to sign off on it.
but in many fields things can be more competitive, or you can have new entries into your environment that will unexpected changes in the dynamic.
This is why early on many senior staffers most places I've worked lead with "COYA" when mentoring younger staffers. It's saved me more than once from bad actors.
I've also screwed myself multiple times when I did.
It's hard to know when to do it.
Instead of continuously second guessing myself, I've settled on preferring trust-based relationships.
Alas, I've only experienced that twice. It was heaven.
Anything short of that is torture. I hate the "Guess what I'm thinking?!" game.
TL;DR: Miscommunication is the norm. Learn to persevere.
Sleep well.
Take care of your body and your mental health.
Try to turn any feelings of inadequacy or imposter syndrome into energy to push yourself forward and increase your skills and knowledge. We've all been there... multiple times.
Learn to code fearlessly: Are you being asked to run queries on a production box? Ask if you can get a user with read-only permissions. Change crusty old code? Maybe put a quick test harness around it.
If you're stuck when debugging a problem, think about all the assumptions you're making, and then test each one of them, no matter how obvious.
Understand that code is often ugly and weird for a reason other than incompetence. Code quality tends to be a function of time, requirements, experience, and skill.
(At least, that's what I tell myself...)
Read the book The Simple Path to Wealth, or the basics in this blog post.
http://www.mrmoneymustache.com/2012/01/13/the-shockingly-sim...
I have a friend with a genetic defect - unless there is a major medical advance he will be dead in about 15 years at 55. He doesn't need as much saved up to retire.
I have a friend who couldn't afford to retire until 75. He really enjoyed his younger life doing things that his body isn't able to do now. Perhaps this is the right decision for you.
I knew someone who saved a lot of money and then unexpectedly died 2 years after he retired. On hindsight he shouldn't have saved as much.
The only wrong answer is not making the best decision you can about.
Does this mean you save 93% of your income and only use 7%?
From the website, there is a graph that shows how many years you supposedly have to save for retirement but it does not take into account the actual amount you make.
As a "junior" dev, if you save 97% of X peanuts you still have peanuts.
As someone working in technology, you are going to be learning new stuff continually (or your usefulness is going to diminish over time). By keeping up to date with tech news, you get a lot of context for what people are using, what's coming down the pipe etc. You may end up experimenting with stuff and then you'll be ahead of all your colleagues. It broadens your knowledge, and if you have to deal with clients it means you will usually know what they're talking about.
There's a few pitfalls to watch out for though. HN is great, but it is still an echochamber that can be focused on web and related tech. I was mostly an embedded software engineer for years and found comments like 'does anyone even use C anymore' hilarious (yes, see Linux kernel, device drivers, and your washing machine for details). It can also be very easy to end up wanting to push for the 'shiny new thing' too early. I tinkered with Rust from very early on, but it's only in the last 6 months or so that I'd suggest it is ready for use in most companies (depending on application area). Javascript frameworks suffer this problem particularly badly. Mature beats shiny 9 times out of 10 - running into a problem that 100 people have met before and posted about on StackOverflow and your tool caters for, is much better than being the first person to encounter said problem.
Interesting because I advise the exact opposite: do not waste time reading HN, just find one thing that is interesting and master it. Then repeat.
As much as I like HN there is a lot of noise here. Novice mind can easily fall into a trap looking for signal here.
(At a former company, working in a team full of very strong engineers, we still found one dialog box of ours end up on that site once, and the issue it demonstrated led us to a bug in the code.)
If you start seeing things on there that look like something you'd have done, don't beat yourself up over it, but learn why those are WTFs and re-evaluate how you're writing code/designing software.
Just be warned that places like this are the worst kind of habit-forming variable-reward site. Worse than Facebook, really. Every now and then you'll find here something that will tremendously improve your worldview, programming skill, or propel your career forward. You might then find yourself using this as a justification for wasting disproportionate amount of time on reading random things, instead of doing.
(Yes, I'm very much stuck in that trap right now.)
1) A senior developer is unafraid of not knowing things. When we join a new team or company, we're as lost as any junior developer joining them team. We ask as many questions as necessary to get our work done effectively, without shame or fear of looking foolish for not knowing things already. We are good at searching through unfamiliar codebases to figure out how they work.
2) A senior developer (or any productive person) is good at saying no. People will ask for more of your time than you can spare. You can gently but firmly say no, direct people elsewhere (delegate), or ask people to discuss with your manager whether more of your time can be allocated to help them.
In my experience it actually leads to Juniors being abused a lot of times being given dumb projects someone should have said no to. Then code review rolls around and the seniors are like “what is this” and there’s a dumb fight. Lol. Maybe that’s just the places I’ve worked.
I wrote up something about it a while back: http://zalberico.com/essay/2017/02/21/asking-questions.html
Strive to maintain a good work-life balance. Burnout sucks. Your health and family are more important than work. A workplace that doesn't consider this to be the case is likely to be toxic.
As for actual software development advice... Beware blanket statements. They can help you develop a low-resolution model so you don't suffer from paralysis, but real-world problems tend to be complex and messy.
Here's an example: if you were building a traditional web app, many software engineers would probably suggest using something like PostgreSQL. That doesn't mean other database technologies don't have their place. However, PostgreSQL is able to adequately serve a large category of problems with relative ease, so it often makes for a sensible starting point. Once you become more familiarized with that domain you'll develop a higher-resolution model and you can begin to evaluate other technologies more effectively. Much of software engineering is about figuring out what tradeoffs to make.
Another example in traditional web apps is using cookies for auth. Using cookies for this purpose is well documented and pretty much supported everywhere. There's plenty of known problems with using cookies for this purpose, but the alternatives also have their own set of issues to deal with.
My final example: testing. Testing your code is great and it can be very useful, especially when refactoring or developing new features. But going for 100% code coverage is usually more trouble than it's worth. It's also very easy to end up writing a bunch of useless tests. You want to focus on the actual problem and not waste anyone's time.
Good advice.
It's likely burnout will really change you for the rest of your life if you don't react early enough.
It's a bit sad when you realize you'll never again be that guy you grew up and identifies as. But you also have to realize that was a person with habits that wasn't sustainable and now you have to live with that.
I definitely don't want to burnout, but I also know that I will need to work very hard for a short period of time until I can exit my current full time job and secure a full time software development position.
Do you have any advice on how to strike a balance between working very hard and knowing when you're burning out?
Read a lot of code, not just code in the projects you work on, but reference/framework source code, open source. Perhaps even ask a subreddit for the language/tool about good examples to learn from.
Realize that data is more important that code for the most part. So treat data like it's precious. That's one part of why I feel relation databases are better than document/object stores. I suppose this is up for debate.
Learn to say No. It's mutual respect to say No so the one asking has a chance to ask someone else. If you instead say Yes to too much and can't deliver too close to their deadline you might screw up other people's time plans.
Outside work: Avoid eating junk food more than 1-2 times per week. Keep your weight. Go to the gym or run. Take the bike or walk to work. Sleep at least 6+ hours a day. Limit work to 40 hours/week. It's better to do 40 fresh hours than 50+ zombie hours.
Languages are tools, and you are a craftsman (or woman). In the same vein, a carpenter doesn’t scoff at using a wide variety of tools and of course has favorites but doesn’t get caught up in them.
Frameworks will come and go, understand how they work under the hood. Understand how Node works, aka V8 engine + C++. Understand why React is so popular but also understand it’ll pass in time as well.
Most of all, just find what you enjoy in programming. If you don’t like architecture that’s totally cool. If you love writing middle tier software, that’s cool. If you like being full stack, totally fine. There’s plenty of jobs in each area so spend time finding what you like.
* You are expected to manage your career and growth. Don’t rely on or expect your manager or someone else to do that for you. You’ll get lots of good advises around how to grow in your career. It essentially boils down to taking initiative and driving those to closure.
* Understand the product end-to-end as an end-user. All the use cases, all the flows.
* Understand the business model, how it relates to the product and how that product (or part of it) in turn relates to what your team and you are working on. This is much harder than it sounds which is why you need to relentlessly pursue this. The code base you are working on has an abundant of domain knowledge and architectural decisions built into it. Build a mental model of both that domain knowledge as well that architecture. You will rarely find those documented so you need to put in a lot of effort to know all the use cases and relate them to control and data flows. Trace different requests through the system, use whatever tools that are at your disposal (debugger, logs, metrics etc.,). This mental model will really help you accurately estimate feature requests.
* Help those around you in whatever way you can. Treat all the functions (HR, finance, marketing etc.,) with equal respect. Get to know them, what they do on a daily basis, their pain points. If not to help them then at least to empathize with them.
* Actively look out for inefficiencies (e.g., build taking 20+ minutes, broken unit tests, chronic production issues) and take time out to fix them. Even if no-one appreciates this you will have at least a feeling of fulfillment of having achieved something valuable to the business/company. In the process, you will have learned something new.
* Make full use of vacation policy. No one’s going to tell you to take a vacation you gotta take care of your physical/mental health yourself.
This is huge. For any junior devs, please take the time to learn about how to plan and enact career progression and technical growth. I learned the hard way that if you don't do this for yourself, nobody will.
> * Make full use of vacation policy. No one’s going to tell you to take a vacation you gotta take care of your physical/mental health yourself.
> Don't stop trying to improve.
can't ever be overstated.
Learn how to write good emails. Write to the point of view of the person/people receiving the message. If you can't describe a requirement without technical jargon, you probably don't understand the requirement.
Learn how to phrase questions and responses in a thoughtful manner. Knee jerk responses are usually detrimental.
Learn how to present. You're going to have to make a case for your ideas in meetings. You'll also have to defend your actions sometimes, particularly with respect to operations and support.
Communication is so critical. It helps requirements become better understood. It keeps issues from becoming escalated so that you have more time to do the enjoyable part of the job: creating something for someone.
Your job is to make someone else's life better with your development skills. Whether it's saving a step in a task they need to do or providing timely information so they can make decisions important to the organization...whatever...you're there for them.
Explore what areas of development you like the most - analysis, project management, UI, backend, etc. - and follow them. Keep in mind that it may change in the course of your career.
Try to develop a good rapport with your colleagues. You spend a large portion of your waking hours with them. It's easier when you like them and vice versa.
Find enjoyment in each job. It's a long career. Don't stay with something that isn't enjoyable to you.
I often have felt that Jr. Devs I have mentored only live up to the "Jr. Dev" role. They only do as much as they think a Jr. Dev should do and often leave work for a more Sr. Dev instead of at least trying to take a stab at something.
Example: a JR. Dev has trouble implementing some candlestick graphs. Instead of trying to work through the issues and document his thoughts in the code and ask for advice. He just leaves it untouched, for many days, then a week, before someone asks him his progress then says "while I can't quite make it happen" when really nothing has happened.
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.
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.
There's a lot of learning to be had in taking the time to read and understand others code, in taking the time to really grok any brownfield system that you're working on, and in spending some time with the documentation.
There's a lot of work you can save yourself by taking the time to assemble a clear plan of attack before you start hacking.
(And if you're doing BDD, writing Gherkin files counts as hacking.)
There's a whole lot of rework, wasted effort, and end-user aggravation that you can save by really getting to know the business domain you're operating in.
When things get their craziest, when entire teams are getting fired, that's sometimes when career opportunities open up and massive advancement can happen.
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 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.
"We don't rise to the level of our expectations, we fall to the level of our training."
"Languages are tools" too, thats my motto. Most things around are tools (house, insurance...) just people do not want to see it.
Find/invent a project of your own only, something thats seems doable and u would really use/need it, and try do it. Will teach u wonders.. about life as programmer.. which is not same as everybody else. Much more philosophy and multiminded-ness is involved.
As of how to find a mentor.. i do mentor people, and it seems a cross between a matter of luck, AND mutual "liking each other". You may have to ditch your ego, and the "i know it all"-ism for quite a while.. and believe me, its more useful to be scolded by someone in the know than to be awed by someone who does not.
good luck
Applies esp. early, but also later, in ones career.
Yes, understand principles, but don't get frustrated because you don't understand everything from the silicon up to the photons coming out of the screen. You'll never understand it all. Try to understand more, but don't try to understand it all. No one understands it all.
I've seen this paralysis stop so many junior developers in their tracks. They beat themselves up trying to get it all before doing anything.
I'm gonna be real; I have only the vaguest idea how the VM works in Ruby, along with it's garbage collection (also, they keep changing it for the better). Yet, I've been programming in it for almost 10 years on a daily basis. I don't need to know this in order to setup some validations in Rails. Sure, it's useful when you hit some problems, but not critical for most work.
Don't fall in love with a random company, expecting reciprocation; wait for the company to show love to you. If you do an astonishing good work and the company doesn't reward you, pull back, do "normal" work, then look for another company. Most companies either show their appreciation quickly and regularly, or never.
In summary try to develop good judgement based on real world experience.
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.
Example: Junior is confused by where to put a new file/module/function in a frontend app and the app is built with Angular. Angular has Models, Components, Directives, Services, etc (I don't really use the framework, but same applies to Rails with MVC, Concerns, /lib, etc).
Learn your framework's constructs so you can frame your solutions in terms of the frameowork. You'll be more productive by reducing the scope of your decisions. Downside: you won't be able to find the 'best' solution to your problem - you are constrained by the framework's model of how a webapp should be built. This is ok, you are learning the ropes, so an increase in productivity is worth the constraint in freedom to choose.
First, imitate and understand why the framework does these things and what problems it means to solve. Once you've seen enough of these patterns/opinions (hmm maybe binding the view to a model manually isn't such a good idea, i've been forgeting and causing memleaks - hey Backbone days!) and have real life examples of where the patterns present problems, you'll be able to improvise/tweak/decide-yourself.
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.
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.
2. Don't write clever code, write readable code. Participate in code golf or obfuscation contests to scratch the itch if you have one, but keep it out of production code, even if its a private project that you will never share with anyone; it will save you from yourself.
If you write something cool and you're thinking "oh yeah! I am such a Ninja!" then step back and decide whether it needs commenting to explain what it does.
If it does need commenting, consider whether you could rewrite it in such a way that comments are unnecessary. Assume your colleagues and future code maintainers are trainee ninjas at best.
I think Rob Pike's 5 Rules of Programming[1] are better advice here -- in particular rules 3 through 5.
Good one. Clever code is really tempting. It feels cool to do something in one line instead of six and call it a day. In many cases, the mature thing to do is to know how to do the cryptic one-liner, but write the six lines anyway for readability and comment them.
Try frontend, backend, write random Bash scripts, try multiple paradigms, try every language out there. Try multiple databases too. Don't just write toy stuff, write something substantial that takes you 2-3 weekends to complete.
All of the best developers I've worked with have mastered at least two languages, if not 3-4.
Will you necessarily use all that in the field? No, you might end up at a Python shop and decide you love programming Python. That's fine.
But you will gain so much perspective on what is possible in programming, and avoid getting stuck in the idioms of certain languages for the rest of your career. It will give you a great design sense. It will give you the ability to dive into any problem, in any language, and be successful.
That last sentence is part of my piece of advice: Try to add stuff (comments, logging statements, etc) to your projects that will make things easier in the future, either for you or other developers.
1- Find solace in the fact that "senior" engineers often spend a significant amount of time searching the web/stack overflow just like you do.
2- Have respect for the code that came before you. Be generous when passing judgment on architecture or design decisions made in a codebase you've adopted. Approach inheriting legacy code with an "opportunity mindset".
Learn to tear down abstractions instead of building them up. As a junior developer, it may be hard to get acceptance for removing layers, but add as few as possible. Somebody is going to come through later and need to understand what you've done, when the stack is deep, that's much harder.
Don't trust other people's code to do what the readme says. If anything claims it's lightweight, count the lines of code and see. If you use other people's code and it's broken, it's going to hurt your users and you're responsible.
On a people skills level, learn how to disagree without being disagreeable. Invite people to share their reasons for things with real questions, and listen to their answers -- while they're sharing you can discuss why to do it their way vs the way you want to do it. This is a good practice for when you are the senior person instructing the junior person as well. Often the senior person is going to make the decision, but having a discussion about it can make it easier to accept.
Don't do this for everything though. Choose your battles, don't be the person who fights everything; unless you're getting good results and people are happy changing everything.
Conversely, don’t spread yourself too thin. Try a lot of languages out then narrow it down to a few you find interesting and useful, then focus on learning those few.
This is one of the things that is dangerous about these code bootcamps you see. They are taught enough to write cogent programs for a given language, but the underlying bits and pieces of what make software tick is left out. There simply isn't enough time to truly learn the craft in a 6-8 week course.
I haven't seen this one so far (but haven't yet read all comments):
Whenever possible, try to avoid bugs. But, even more importantly: When given a bug report, FIX the damn bug. Don't:
- Shrug, mutter incomprehensible things and wish the person with the bug report goes away (yes, I've seen that. It infuriates me.)
- Say "that's not possible" (cf [1]). It is. It happened, no user makes this stuff up for fun.
- Say "that doesn't happen on my machine." Well done! Now make sure it doesn't on all the other ones, too!
- Say, "well, if you had configured it right,...". That's also a bug: Your documentation sucks. Fix it. Also make sure impossible/nonsensical configurations are visible (best done during startup, for example).
- Avoid commenting on the report/contacting the author because there's not enough information. Tell them you need more, what they must gather and how. If you tell everyone the same things, write a HOWTO and link there.
- Ignore bug reports. Valid reasons you're not fixing a bug are 1) you're currently busy fixing another, more important one or 2) you already understand the bug completely and have discussed the tradeoffs involved with others (write a WONTFIX with sound reasoning, please).
To sum it up: Be helpful to your users/admins/etc. Don't be a "Code Monkey".
[1]: http://plasmasturm.org/log/6debug/
Edit: Formatting, reference to 6debug :)
Its called "self.debug - An Emotional Guide To Being A World Class Software Engineer" - you can download it here (its free) - https://leanpub.com/selfdebug
Feel free to provide feedback on twitter to me.
But if anything this simple rule is the best: K.I.S.S. (Keep It Simple and Small) Make small things. If you ever find yourself saying "do this and then do that" your talking about two things and make them two things (separate functions/objects) and name them.
Also - I have been coding for 10 years now (as of September). It’s interesting to see as I gain experience the biggest differences looking back are (1) I choose to use more git branches and release 1:10 ratio smaller commits. (2) I try not to ever go back to “refactor” or clean up code and instead spend time on changes to accomplish the next feature or bug fix. (3) I never plan ahead and think “what happens if ...” instead focus on the present. In reality the future often never comes or it looks different than expected.
When seeking a job: It's not about you. It's also not about the company you're working for.
When improving the ugly code in the job you just started: It's not about you. Don't argue about silly things like brace styles.
The more fond you are of your tools, the less likely you may be to try others. Don't develop preferences too quickly. Try not to emotionally invest yourself in decisions you've made about languages, libraries, editors, operating systems, and other technologies that you will spend thousands of hours with. Technology changes so quickly that you can easily find yourself mastering a local Maxima where others have already left and moved onto higher ground. Try new technologies and adapt with the times.
2) Learn to love working on legacy codebases. This will happen everywhere you work. You will rarely (if ever) have the opportunity to start from scratch. If someone asks you to use an existing piece of code, and you decide to re-write it because you don't want to take the time to understand what's going on, you will A) appear to be anti-collaborative and B) reinvent the wheel, thereby wasting time. Obviously, there are scenarios where re-writing something from the ground up is necessary, but make sure all stakeholders involved agree and that you can estimate it correctly.
3) Always try to coax out as many details from designers and product managers/owners wherever possible. Perfect requirements will never exist but you want to be equipped with as many use-cases as you can before you start hacking on something. This may sound a bit waterfall-ish, but PMs and designers are not omniscient creatures. There is almost always some sort of gap that you may be able to help identify.
4) Don't be a dick, because there will almost always be someone who knows more than you. This applies to comments in PRs! Even if the entire company treats you like a god, that does not give you the freedom to treat others like worshippers.
5) If you are asked to estimate how long X will take, DO NOT give an answer until you have enough details so that you can make a reasonable estimate. If they force you to give one, pad it 2x or more depending on how much you don't know about what needs to happen for the task to be marked 'done'. Even better, ask them for a separate fact-finding task (spike, POC, or whatever you want to call it) so that this can be more easily tracked.
I could go on forever but these are some of the more non-obvious things I don't hear talked about enough.
Write code for fun. Find a hobby away from computer for sanity.
Consider the risk of burnout - even with great mentor and challenging work a toxic environment is not worth it long term.
Care about ergonomy of your workspace now - adjusting height of monitor costs you nothing, good keyboard and wrist rest cost less than you make before lunch. Carpal tunnel, ulnar neuropathy and back problems will start hitting you and your friends when you are teaching peak of your career and are no fun in general.
Biggest issue I find with developers right out of school, is that they often feel ok throwing a problem over the wall to a more senior dev. The truth is, all of us are confronted with problems we don't know how to solve. That is the job, but if we don't solve them, who will? You will not magically discover an ability to solve impossible problems and diagnose inscrutable bugs. But if you don't give up, and you fight your way through these problems again and again, you will develop confidence, and the instincts that allow you to do it a bit quicker next time.
On a related note, do NOT rejoice when a bug you've been struggling with suddenly goes away (another thing I've seen many times). Nasty bugs "going away" is one of the worst things that can happen. I promise you, 90% of the time it's coming back. And it's coming back at the worst possible moment, and possibly in a less friendly form.
The mistake I see all the time is juniors nodding because they fear letting me know they don't understand is a weakness. A sign they do not master the language (in fact I see this with most people). Always ask questions. It has multiple advantages: (1) it answers your question so you can understand, (2) it shows me you want to understand the topic under discussion, (3) it helps me explain the topic by guiding me to the parts you find complex, (4) the nature of your questions shows me how much you understand of the topic
Being able to stop someone and ask what a particular term or concept means is a super important skill for any engineer. It does not list you as a fraud, it lists you as a great learner. Remember that. Always.
Now, when asking questions ask the right questions. There is enough material here for me to provide just two links and let you google for the rest. [0][1]
P.s. Bonus reason: Assumptions are the mother of all f*ckups. Ask to verify things you think you know!
[0] https://jvns.ca/blog/good-questions/ [1] https://hbr.org/2018/05/the-surprising-power-of-questions
Some things you can do for example:
- Using linux? Learn to use the CLI
- Learn to use git/svn/... (whichever you use at work)
- Get comfortable with your IDE (shortcuts, customize to your liking, ...)
- Learn to use a profiler (JProfile, ..)
Those are some pretty general things but they'll help you in any job where you write code.
The tools are (imo) just as important as knowing the language you use.
- Confidence comes from trying, and failing, and trying again.
- Burnout is real. Know when you are close to it by knowing what triggers your anxiety and stop. Having the ability to remove yourself from a stressful situation, even if just for an hour makes all the difference .
- Test your steps. If you can write code to test your steps then it's great but most of the time a simple browser reload/button click or command line run action with verify if your change works will be good enough.
- It's fine if you don't know. Having the ability to ask for help will mostly be met with respect.
- You are not defined by your code as a person :)
- Theoretical pureness mostly gets in the way of solving an actual problem because of the endless debate it sparks in a team. If your goal is to write code that is readable for someone in the future then it doesn't matter what design pattern you use. Computers are fantastic at understanding code. Humans however need some help.
- Try and clean up as you go. Like your home, if the dishes pile up too much it becomes unliveable.
- Lastly, learn how to understand legacy code. It's a fantastic snapshot into the way the business was thinking at the time and to see it evolve and be that change is a privilege to be part off.
Don't trust your manager(s) that they are going to lead/manage/mentor you in a way that will really help you. They are not.
If I allowed myself to be really cynical, they are mostly out for themselves. Most will have no problem using you or even throwing you under the bus to get themselves ahead (or protect their own jobs). And this involves things like having you do things (aka work with less valuable techs) that they don't want to waste their time with. That is what `delegation` is.
But don't worry though. Most of the time, they have little time left to think about ways to take advantage of you. They are just busy managing their own jobs, your fellow team mates, and their own bosses. Oh, and figuring out how to beat fellow managers. They have their own family/retirement-plan to take care of. They don't have much time left to manage you after sharing extended pleasantries with their own bosses.
And the more successful your manager seems, the more guarded you should be about them using you to their advantage. I've been around and of the bosses I had over me, two are now in high level position (VP) at really well known brand name companies in US. Because we were in smallish startup shop with cubes/offices near, I was able to observe them from nearby. Both were really good at pleasing higher ups (not necessarily through excellent work but with friendship), have no problem with pushing around those under them, and just do good enough job of actually managing the team.
Also, don't settle. Don't settle into a role that you feel comfortable. If you feel comfortable at a role, it's time to move on. And time flies. Make most of it.
Avoid what is known as 'Somebody Else's Problem Field' behavior. (Here is the link: https://en.wikipedia.org/wiki/Somebody_else%27s_problem)
What I mean to say is, a lot of times developers have an attitude which says "I'm done with my work, now if its not working, it's somebody else's task" or variants of that dialogue. As a developer, I understand and concur with your position that you might have done all the things right, but as a team, you are not helping matters by saying that. Volunteer to check your code, do more, and try to figure out where the problem is, like what input you are getting, what is the output, where is the code failing. the more you help in these cases, the faster the things get done.
This is also a common behavior, when someone asks you for a data or a piece of code, and you send her a straight forward export/import in the raw format. Occasionally, that might need the other person to do a lot of clean up and other operations, (with a bit less context), and would have been easy for you to do in the first place. As a developer I did that a lot. On the receiving end, this is one of the most frustrating things, since I need to account for it in my tasks beforehand. (Example would be a simple dataset, given to me at SKU level - cos requires a straightforward query - while if extracted aggregated, would have taken 5-10 more minutes for the developer, but now the asker is expected to spend sometime cleaning up and aggregating that data set. Might not always be this, but I hope you get the point.).
my 2 cents.
Figure out what parts of the stack you're more passionate about. This may shift over time, but if your working on things that you truly think is interesting it will keep work from being work.
Most importantly, junior software engineers and interns often complain that the work they do is not impactful - it may seem that those around you are doing impactful work (and it might actually be true in a very few cases), but don't let this effect your peace of mind and not let you give your best. Every work you do must show a characteristic of your quality. Engineers must be able to provide anything in their field, at all levels of their stack, regardless of how important they feel their work might be. Always respect your work and be grateful for getting an opportunity for working on it because someone did not get that chance.
It sounds silly at first but for those of us who like to share what we learn, or think others aren't interested, we love it when anyone has questions for us!
Don't be afraid of failing a lot either. Personally I've learnt a great deal of things just because I tried to do nonsense things that failed and taught me a lesson.
I first dove into unicode (and did a talk at a meetup) because I had this absurdly stupid idea to make a program that "prints hotdog emojis every X minutes". It didn't work but just asking "Why?" lead me to a lot of answers and even more questions.
You never know when seemingly useless info comes in handy again (like obscure modules in the docs for your favourite language)
You'll probably have plenty of times where you know that "if I write this line of code, this thing happens, and that solves the problem". Dig into exactly what that is doing and understand why it works as it does. A lot of the time this just means reading all the documentation (not just the 1-liner you can copy/paste and move along) and source code of libraries.
A good exercise you can do is to open up some code (ask a coworker for a good place to start), look at it line-by-line, and ask yourself if you know exactly what is happening on each line. You probably won't know and that's your trigger to go read up on something. From there you'll have great questions that a coworker should be happy to talk about with you.
In my experience, new developers that take this approach of truly learning (rather than just making things work) grow fast and impress the team.
If you never say "that estimate is too small" then you cant blame manager for assuming the estimate is good. Saying no is an option, learn to do it politely.
Sometimes manager is pressuring you, sometimes he/she really just asked when it is going to be done. Don't panic, answer truthfully.
You cant make up tomorrow or next week for time unexpected spent on something else or just wasted. That is not how it works. Factor that into estimates (whether formal or informal).
Why:
1. Chances are you'll meet very interesting people, with a background different than yours. This is invaluable, in my opinion
2. You'll understand how the organization works and how information dissipates.
3. You can learn about their jobs, and if possible, find ways to make their jobs easier for them. Do someone a favor, they'll most likely return it.
3. Networking can provide very interesting opportunities in the future
4. You'll get perspective from outside the technology bubble
Physical exercise. If possible, try to do it at least 2 days a week. Besides the obvious physical health aspects, regular exercise is a performance boost for intelectual work.
Best of luck!
Even if the questions sound silly, which is what terrifies the most, just ask. At my first job, I was too afraid of asking my teammates unless I came up with some smart-sounding question.
Fast-forward a couple of years until now: I have a teammate who is quite less experienced, and revealed me he does not want to ask questions because he thinks it's a waste of time for the other person and/or he feels silly to the whole team.
I attempt to mentor him and teach him to ask questions, no matter how dumb may be. We've always been there.
This leads me to another aspect: have empathy towards your colleagues.
Be a bit sceptical of people who pass out judgement and advise
What is important is a willingness and skill to learn new stuff; all else is in a flux.
Also I don't like this distinction between junior and old hands; it can make you complacent.
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”
Which is a fluffy way of saying when you tell someone at 4:55pm "I'm leaving now but I'll get to it first thing in the morning", you actually do it first thing in the morning.
There is no better source of knowledge than solving software issues. You see it all in that backlog. Deployment issue, build issues, bug fixes, feature changes, merging problems, log files, web server configurations, DNS issues, certificate installations, database errors, database updates, connection issues, you name it. It is in there.
Once you feel comfortable with that backlog, look at the source code of your application and you will then ask your self, WHY IN THE WORLD WAS THIs BUILT THIS WAY?!?! you will find everything wrong with the application and that is a good feeling.
Start with Supporting an application before developing it.
1: Never trust a recruitment agent.
2: Don't be afraid to ask questions. I've had 30+ contracts in 18 years, and I've lost count of the number of times I've been in a big meeting where some manager or director is specifying something which makes no sense, and all the other developers are just nodding quietly. It saves a LOT of time if someone politely says "sorry, maybe I'm being a bit dumb, but I don't understand" right there and then. 4 times out of 5 it turns out that nobody understands, including the guy talking about it.
I know there is a lot of stuff you do not know, and it can be truly overwhelming to try to stop, and read for 20 minutes when your parsing might get you the answer you want in 1. But you will learn a lot more, and you will start running into issues less and less frequently.
In the long run, it will genuinely save you time, and you will understand the tools you are working with much more deeply.
Ask whether you can sit in on calls with customers, either prospective or current. You will find out what they want, and whether your product is solving their problems.
Writing some React code and it doesn't work for Chrome on Linux?
You should in principle be prepared to debug not just your own code, but React's internals, the Chrome JS engine, and the Linux kernel itself until the problem is identified.
Obviously that sort of thing is a last result, but you should in principle be prepared to do it.
It will be golden six months down the line when you're questioning your career.
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.
Be Honest.
Be Humble.
Respect self and others.
Practice diligently.
Seek perfection of character.
And would also share the following quote from Hiroshi Saito (CEO of Chateraise) which I came across later in life and thought it helps to change your perspective:
Everything outside of me has something to teach me.
This change is starting to emerge and the programming opportunities for the future will start to erode.
It can be both your portfolio and motivate you to keep pushing the envelop.
I do these short little exercises in programming to explore different concepts. Usually make a rough POC for an idea or some kind of interface.
Ask HN: Senior developers, what would you tell a younger you?
Draw lots of doodle-diagrams, then throw them away. Draw again.
Watch YouTube videos. Some people learn better by watching.
Above all, code a lot. If it doesn't make you happy, quit. If it does make you happy, look for more ways to improve your personal learning style.
Writers write. To become a better writer, write more.
But then I've always treated programming as a form of communication. Maybe not literature, there's still beauty, awe, and whimsy to create and behold.
Practice things like TDD to ensure you have a good set of tests that will allow you to maintain the software for years to come.
don't listen to management team saying "this guy is the best developer I've known" - his code still might be crappy
put "solved" after the phrase you're searching in google
always have your CV ready on your computer
It'll give you a lot of higher level things to think about as you're diving deep into your first tech stack.
Where to live, what apartment to live in, where to work, who to become involved with, what bed to get, etc.
Nootropics. Cognition enhancement. A multivitamin + D & K + chelated/TRAACS magnesium supplement. Meditation and/or brainwave entrainment audio. Stress management. Ensure quality sleep.
Nootropics that increase verbal fluidity tend to be great in corporate environment, especially as it becomes clearer what leads to a promotion/raise.
Being promoted every other year (0 = entry, 2 = mid-level, 4 = senior, 6 = staff, etc) is conservative/typical/traditional. Fast risers get promoted every year. Move around, especially if your job isn't great or well-paying, to maintain a pace.
Though an engineer, still network. Weak ties are better than deep friendships when networking. Approach all as though they are friends. No need to let someone draining waste your time. Cast a wide net, but choose wisely.
Don't let them work you to the bone. Startups fail 98% of the time (78% if BS exits are included) and corporations typically don't care about you.
Your employer owns everything you develop on company time or using company equipment.
Understand the business, users, and political landscape at your company. Avoid getting involved in politics and gossiping. Commit to maintaining ethics and professionalism, then set everything up such that it doesn't sabotage you.
People tend to be selfish, two-faced, and unconcerned about you. Smile and be happy while remembering they'll likely stab you in the back with little hesitation.
There's being irreplaceable and there's them knowing/thinking you're irreplaceable. Only the latter matters.
Many years ago, it was estimated that 4% of executives/CEOs were psychopaths (versus 1% of the general population). A study released in 2016 now puts the estimate at 21%.
Read, read, read, read...
Avoid stagnating and blindly following whatever's said. Things change and the world has little problem leaving you behind. Staying fresh/competitive can be difficult, especially as many companies heavy-handedly try to push you into the trap.
Take-home salary: 20% to savings (max out 401k even if just up to company match), 30% max to rent, and 50% toward expenses.
house_price <= 3 * yearly_salary. 20% down payment. mortgage <= 2.4 * yearly_salary.
Car: down payment >= 20% of car's value, finance period = 4 years, principal + interest + insurance + license + registration + gas + maintenance = 10% of one's gross monthly income. Buying without taking a loan is even better.
Ageism. Software Engineers have an expiration date. If not in management or a founder/consultant by mid 30s, things can easily get difficult.
I’m not an algorithmic genius don’t get me wrong, that part doesn’t appeal as much to me.
IMO: Being too comfortable in the same position is not good enough
Asking questions like "How does this work" can be the fastest way to learn.
Trying to make computers do the things humans do well is nearly impossible.
1. Think Big. I have seen many people who aimed higher from the beginning and did manage their way up (e.g., becoming a VP in just ten years, that too in a large company).
2. People skills is a must. You should be thinking of people or organizational challenges all the time, or you'll miss the mindset to rise significantly up.
3. Many people complain about their team leads, managers or senior leaders. This usually happens because these senior are working at a higher level of responsibility and ambiguity than you are. You should rather be thinking what would you have done if you were in their position. Understand the challenges they have, by directly asking if needed. This will not only help develop your relationship with them, but also position you to develop the skills needed faster, without yet being in the position of responsibility that they are in!
4. There is a lot of entropy in any team/organization, and unfortunately also a lot of people who are increasing it. Be the one who reduces the risks and brings order to the chaos, whose judgment can be trusted. Keep in mind for this that the real challenges are often not on technology side (in other words, if you think technology challenges are more critical, you are perhaps missing the big picture).
5. Try to become irreplaceable for the team/company in your project and beyond. In my experience, this will not come in your way as [6] suggests. You must however not get limited to the tools and technologies specific to the company, or else your market value will suffer within a few years.
6. Never say (or even feel) anything bad about anyone ever, keeping Hanlon's razor in mind [1]. But then, how do you deal with the stupidity? Well, <b>their stupidity is your opportunity</b>. (I created this out of Jeff Bezos' famous quote, "Your margin is my opportunity." [4])
7. Do not let yourself be masked from political issues around. A good manager would aim to mask you [5], but that can curb your growth since you won't develop the skills needed to master and survive corporate politics while being masked.
8. There are books available today that teach you corporate politics [2-3], showing how easy it is for anyone to do it, and how difficult it is to counter. Reading these books should be a required reading for anyone aiming to go significantly high. And trust me, it's better to learn this from books or from other people's experience than learning this stuff the hard way. (The latter would be painful for one, and second, you may never actually learn.) I have read [2] and felt that I should have read it earlier.
9. Ask questions whenever you do not understand something or if your own thoughts do not align with the decisions being made. Of course, be polite in this (e.g., "I was wondering if option X also has been considered" instead of "why are we not going for option X"). People around would be happy to explain to you while also developing trust in you, and often would take the suggestion if it will actually reduce their mental burden. The sooner the better in asking questions.
[0] https://news.ycombinator.com/item?id=16490323
[1] https://en.wikipedia.org/wiki/Hanlon%27s_razor
[2] https://www.amazon.com/dp/0743262549/
[3] https://www.amazon.com/dp/0312332181/
[4] https://www.inc.com/jessica-stillman/7-jeff-bezos-quotes-tha...
In seriousness: get exercise. If you aren't in good shape it's draining, and making your life harder. Coding is hard enough
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.
TLDR; I would give an eye or a hand if someone had given me this advice when I was 20.
Related to this is realizing that most software degrades over time, being touched by many people under varying deadlines. Assume best intentions of your teammates until you _know_ there's a endemic problem.
Read code. Don't despair if you check out some cool OSS project and a lot of it is going over your head: pick another project or start consuming the code in small chunks.
Don't engage in bikeshedding.
Don't be an asshole.
Always be able to explain _why_ you: picked that solution, developed it that way, favor X over Y, etc. Explain your thinking.
The "right choice" is typically right at the time the decision was made; time will usually erode that "right choice" until it looks wrong.
If possible, document the reasons why critical/large decisions were made in the project/codebase (e.g. "we had to do this like X since system Y wasn't compatible with system Z at the time of writing").
Think of the next developer to touch your code. Think of you touching your code 8 months from the time of writing. Both will help you documenting the "whys" of your strategies if it may not be abundantly clear.
Follow coding conventions of everyone else at your company; don't try to buck the standards.
Don't be cynical. Don't be a source of constant negativity. Those people suck to work with.
Find programming forums/message boards and consume at least a few times a week.
Don't obsess over picking the "absolute right solution", pick the one that sucks the least given the information on-hand at the time. If it's a big choice, document why you made that choice.
Do not burn out. If your company commonly features "death march" projects, seriously consider leaving. I suffered a nervous breakdown around 5 years into my career by working 60-80 hour weeks for months on end while dealing with veiled threats about all our jobs. This was during an economic downturn and an especially hard time to find dev jobs, but I still think it would have been better in the long run to leave. I believe our company, knowing the tough local market for devs, intentionally grossly overpromised on a deadline to a huge customer because they knew many of us wouldn't have many options. I probably made less than minimum wage that year, never did the math.
Related: in many cases, the company is not loyal to you at all. Do not devalue yourself for loyalty to your company.
Always, always give credit where it's due. Never take credit for another's work or ideas.
One of the best things you can do for teammates is relieving them of stress and sharing the burdens; leave no one on your team behind (metaphorically). This obviously depends on how close-knit your team is, but there were many times I stayed late to help a close teammate with a production problem that technically I wasn't directly involved with. When they did the same for me, I was very thankful to have that other set of eyes, the person to discuss the problems out loud. I know together we solved those problems quicker, to boot.
Your project will be cancelled and your team will be reorganized. The manager you love to work for will leave.
The most important part of writing software is being able to understand it. You should be able to understand it when you're writing it, debugging it, and six months after you haven't touched it. Other people should be able to understand it. That principal informs the following rules:
1. Code for simplicity first. Do the simplest thing that can possibly work. For whatever reason in this industry, people are seduced by cleverness and complexity. You're doing a job, not trying to prove how smart you are. Clever code that is hard to understand isn't smart. The problem you're working on is probably simple. Don't try to make it fun and sexy when it isn't. Don't make something harder than it is because it would be cool to use the new shiny ____ to write it.
2. Don't repeat yourself. This is the opposite of simplicity, and your problems compound the more you do it.
3. If you have code that you are afraid to change for fear of breaking it, you've failed to make it simple and understandable. All the testing in the world won't help you if you don't understand the black box, and need to change the black box.
4. Code for readability. If you can't look at a line of code or an error message and understand what's going on, you've failed to make it simple and understandable enough. Functional code helps here; if you have to navigate between 50 different files to understand what a function is doing, something is wrong.
5. YAGNI. You will never, ever, ever need the thing you're about to spend time on and that dramatically increases the code complexity. If you ever do, it's much easier to refactor something simple than it is to work around something complex that made the wrong assumptions. Build systems in small steps.
6. Use the compiler and type system. Everything should be as strongly typed as possible to prevent future you from messing things up. The compiler is your best friend; make it work for you and write code so that when you inevitably have to change it, the type system prevents you from making a mistake.
7. Get good at debugging. This is a skill that you develop that nobody teaches you for whatever reason. When you're writing code while thinking about how it will be easily debuggable later, you're doing it right.
8. Use spaces instead of tabs. You'll make more money. Also turn on visible whitespace in whatever editor you're using and delete those silly extra spaces on the end of lines. I can see those and they're the code equivalent of walking out of the restroom with toilet paper on your shoe.
Rack up experience. It's much better to be working than not working. It is much better to have 2 years of experience and learning vs. 6-9 months looking for something perfect -- this is especially the case for juniors. Just take the first job you can get. Also, don't underestimate how much the rate of learning differs between various workplaces.
Try to work somewhere that invests in people, especially juniors. Startups will be "more fun", and you'll likely to get to work you're not really "qualified" to do, but you won't learn how to do it well. One of my biggest regrets is not finding effective mentors earlier in my career. Sometimes a more "boring" workplace is better for this.
Most employers will judge your skills by the brands on your resume. This mostly happens because there's no other reliable way of determining how good someone is when hiring them, short of "I have personally worked with this person before and can vouch for them" (the gold standard). A mediocre developer who managed to clear Google's bar may be less of a good hire than someone who worked diligently at a consulting company -- probably not in the average case, but it's possible. Note this contradicts a lot with the last piece of advice. It's a puzzle -- brand vs. skills.
Focus on your social network. Most good jobs, especially in more senior roles, will be obtained through prior coworkers, investors, or other people you know/have worked with. Keep up with people. Try not to piss people off. You'd be surprised how useful it can be to leave a trail of goodwill behind you.
Understand that it is management's job to advance the shareholder's interests. Most of the time this means they'll try to do what's right for employees. But it also means that when the situation demands it, they will lie, withhold information, fire people, report things to HR, and try to pay you as little as possible -- that is their job. Filter every announcement and communication through the lens of "how does this advance shareholder interests"? It's not fair to say "everything management says is bullshit", but it's directionally correct. Truth is not the priority.
Focus on developing skills that won't become obsolete. This means prioritizing domain knowledge, CS fundamentals, etc. over the details of one language, company, or programming environment. Try not to specialize in writing software per se -- the market rate for this is rapidly heading to zero with outsourcing and remote work. My friends who have the best careers (happiest, best-paid) are people with very deep expertise (PhD + 10 years experience) in areas like semiconductors, networking, or a particular business domain (e.g. hospitality/travel, high-frequency trading) . The trick is not to specialize too early -- wait to find something you really love.
Most startups aren't worth it. Some are. Many people have a binary view of this: "startups good"/"startups bad". It depends on the people, the market, and a lot of other factors. There are a relatively small number of investors and founders who can reliably beat the averages. But not many. Informational advantages in this area are worth a lot.
Silicon Valley is basically Hollywood. People move around a lot. Packs of people who work together cross-recruit into new companies all the time. Try to get into one of these "tribes". It will help you immensely for your entire career. The PayPal mafia is a great example of what I'm talking about.
As you get more senior, do your homework and really stress out about which job to take. It's worth it. This might be counter to what a lot of others say but IT MATTERS. It's the difference between working your ass off for four years and getting nothing, vs being able to afford a modest retirement after 4-6 years.
Plan to work 3-6 years in places, if not longer. It demonstrates commitment and people in the upper echelons of business (investors, CEOs, high-level management) respects that a lot.
If you work at a startup, don't always optimize for the biggest stock grant. 0.5% of a company that fails is worse than 0.25% of a huge success. Understand that bad companies fail and good ones sell for tens of billions. Our intuition wasn't built to handle 10 orders of magnitude differences in outcome.
I blog about a lot of this. http://davidralbrecht.com/
Being a software developer is easy, I've seen loads of them, these are the people who's work I end up fixing, it stresses me out and it costs the company more because they've paid two people to do the job.
Being a good software developer is a way of life; if you're going home after work and looking at ways to improve your life or other peoples lives by writing software, you're doing it right.
Work with the best people you can find, the more experience these people have than you, the better. Learn what you can, and make it your aim to be the best, one day they'll come and ask you for help. This is the point where you thank them.
Find something you're good at, find a niche language in your company or tool set and become the go-to developer for it. As soon as you attain that, and you're known as the go-to, find something else, work on the new thing, and maintain the old, find languages you enjoy and master them.
Eventually, you get to a point where you're asked to fix/write code in a language you've never used, and yet, with the API docs at hand, you don't even skip a beat.
Also, remember this, no matter what you think, not everyone is far better than you at this. There are some exceptional developers, but most are either putting in a lot of hard work for the results you see, or they're average.
Finally; Never release on a Friday, and never make changes to production.