I'm fairly poor at the second so all I'll say is that being good at the politics/communication becomes more important as you become more senior and is ultimately more important for your career than being good technically.
Technically, the most important thing I learned after I graduated is that state is the most important thing in production systems. Programming paradigms, system architectures, and design patterns are all rooted in managing state. Almost always by constraining it.
For me the critical talk on this was Rich Hickey's "Are We There Yet" but I'd been writing functional code for a couple years when I saw it. When I've directed people to it they find it weird/confusing and have more success with "Simple Made Easy" which I find similar but less insightful. A focus on state first has been the cornerstone of my development philosophy since 2009. It's not universal (e.g. data oriented design) but it's my one weird trick.
I'm a visual thinker and visualize a piece of state as a gas that leaks through calls and variable scope. If it's in the database it leaks through queries accessing the table and the services that expose it. The fewer things state touches, the better because people fundamentally are terrible at understanding interactions over time (e.g. three body, double pendulum). Seeing the state flow through the system tells you how well it's designed/built and where the problem points are.
- Don't ever be pressured into regularly working overtime because someone claims you're not "passionate". You're entirely welcome to only program during work hours
- Learn to use a debugger well
- When a user has an issue with your software, make sure they give you a step by step recount of how the issue occurred
- Unit tests may seem like a waste of time, but are unfortunately very useful
- Find a niche you enjoy. If you're developing software you're not interested in, you're going to quickly burn out
- Don't always chase the new and shiny technologies (unless you're really interested in them), many of them will never become successful.
- You don't have to be the next Zuckerburg to be successful. You can make a very comfortable living as a developer doing a job you enjoy, don't constantly chase trying to become a billionaire and focus on progressing your career via the usual channels
You never finish learning. People who tell me "I know [technology]", invariably are not experts. People who tell me "I am expert with [technology], but learn new things all the time", get it. If you don't like learning _every day_, get out now.
On that point: becoming an expert at a specific technology is great early in your career. You need to be great at learning new technologies as your career progresses, so consider learning how to learn as a priority over learning a specific language or framework, and be curious.
Working with good managers is more important than working with good engineers (trust me, the main difference between a FAANG and a failing startup is management skills), but working with bad engineers still sucks.
Using something that already exists that does 80% of what you need it to do, is normally a better win then writing something from scratch that does 100%. That 80% might even be too high - the real number could be as low as 50% or even 10%.
Mentoring is the best way to develop your own skills by orders of magnitude, but it's also one of the hardest. Look for opportunities to mentor and be mentored, all the time.
This is really important. A lot of software engineers love to solve problems with a technical challenge. It can be more rewarding to understand the business side of things and be able to come up with cost effective solutions.
This also applies to operational processes. In some Saas companies the software is so difficult to operate that you need an army of technical consultant running custom queries and setting up ad-hoc cron jobs to keep the thing working. This happens because the dev team is focused on delivering quickly a feature and is not incentivized to work on admin tools or automated deployments. If you are able to streamline those operations everyone will love you.
I agree, but I'd say that sometimes could be good to write that 10-50% from scratch, maybe for a bunch of reasons.
Don't make it your responsibility to fix management mistakes. Few things are really urgent. Don't work long hours because of an arbitrary decision to ship on the 15th. Deadlines are missed all the time, and it's rarely a huge deal.
Consider contracting. When you have enough money, you can stop taking contracts and spend time on things you love. That can include programming for fun.
Remember that a lot of what you do is mere convention. Don't assume that everything is a certain way because of a deliberate decision. You can cancel meetings, question rrequirements, change policies and take the initiative. This tends to yield better rewards than mere toil.
It's perfectly fine to be passionate during work hours and live your life the rest of the time and people shouldn't be shunned for that
I thought the solution was to program for fun as a hobby :-)
Participate in good faith and if you think you have a valuable suggestion, make it. Best case scenario, it's taken on board and people think you're great. Worst case scenario, it's ignored, you move on and still get your paycheck. If you feel the ratio of bad decisions to good decisions is too high, just find a different job. Trying to change a bad company is like trying to change a bad romantic partner. Maybe it's possible but its a huge investment.
Don't be dogmatic. Don't get angry and don't be obstinate. At the end of the day, it will just wear you down. In my experience, you'll get further as the good engineer who can compromise when necessary than the great engineer who is unyielding.
Overall the best outcome is you put in your contractually obligated hours, do work that is mostly interesting or fulfilling in some way and then get your pay. If you want to execute on some grand vision or produce work that is a true reflection of you as a person, do it in your spare time or start your own company.
Consider avoiding working in cost centers, try to join profit centers.
Better putted here: https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
Kinda soon you'll be in a position where others look up to you, thinking they'll never get as good as you, while you still think you're a total noob.
If coding, don't do everything from scratch.
I've seen multiple people losing interest in their projects, because they didn't even really start them. It's almost always parsers, they (my old me included) write their own parsers for stuff and then lose interest in the idea behind it.
Being nice is a superpower. So is staying calm (especially when others are not). Also, being helpful - especially to people outside your team. When people like you they’re much more likely to help you, possibly in ways you won’t even know you about.
Remember that your users/customers are also people trying to do their job, and get through the day or week, just like you are. Try not to make their lives harder than they already are.
Try to understand where others are coming from, especially in disagreements or multi-team discussion. No-one ever has the complete picture, but very few people (none I’ve ever met) are truly malicious. Don’t mistake a different set of priorities for incompetence or stupidity.
Build something you can show off. A web application, or a mobile apps and stick it on Github or Gitlab. The fancier the better, but even if it's a fairly low effort tutorial clone that's a lot better than nothing. If you can pull out a phone and show off something you built in an interview, it certainly helps you stand out.
A few technical ones that come to mind:
- Try out different programming languages. This enriches your toolbox and can make you see programming in a new way. You can't know if e.g Python is a great language when you have nothing to compare it to.
- Get familiar with a cloud provider's offerings. Doesn't really matter which one since they are comparable, although I'd pick either Azure or AWS, these cover most of the market.
- Get familiar with the debugging tools.
- Learn VCS. Sounds obvious but if my experience is anything to go by, far from everyone is comfortable with git.
And some non-technical bits of advice:
- Ask for help if you get stuck. If you're a junior, people expect you to get stuck at some point, don't be scared to ask for help. Better to just ask than to waste a few days.
- If you interact directly with customers, learn to speak _their_ language. Be able to explain technical things to a non-technical audience.
- Related to the above, practice soft skills. They don't come naturally, like any other skill you can practice them though.
http://softskills.audio/ is a goldmine in this regard.
Your learning process should mainly consist of reading and writing code.
- complicated or unreliable build
- debugging with traces, sometimes traces are not even reliable
- slow flashing
- low acceptance of verification: Valgrind (on target), Coverity (on host)
- and worst of all: unreliable hardware.
Of course each of those items teach you something, although that's mostly patience and rigor :)
Suggestions to keep high efficiency, high motivation:
- maintain your build, fix it when partial build is broken (no "make clean all").
- optimize flashing speed
- find and use a good code indexer
- find/buy tools that will help you find bugs early: Valgrind and Coverity are in this category
On the flip side, if you're in a job that has toxic people, insane management, or lousy pay, don't stay because of inertia or laziness or a hope that it might get better eventually. Start looking.
Specifically about ageism: I have not seen it. I'm 58. What I have seen, though, is that I'm very expensive. I have 35 years of experience, and I expect to be paid like it. If someone want to pay me like I have 5 years of experience, that's not ageism, that's being cheap. If someone doesn't see the value in 35 years of experience compared to five years, fine, I'll work somewhere else.
For me to get away with this, I have to actually be more valuable than someone with 5 years of experience. I'm in embedded software, and it's easier for me to do so in that area than in, say, web programming, partly because the underlying stack changes more slowly in embedded. But also, I've had to keep growing in my ability to deliver what my employer wants in a timely fashion. I don't make as many design mistakes as I did before. I don't write as many bugs. I don't start down as many wrong paths. I don't work insane hours, but I still get more actually done and working.
If you can deliver more value per time, then you're worth more money. Do that and you won't have to worry about ageism.
- You don't need to memorize a whole language or its documentation to be a good dev. It's way more important to learn how to solve problems.
- Don't be afraid to use "boring technology". You don't have to ride the latest wave or jump on any hype train. Languages, frameworks and libraries are tools and while it's important to know what to use, your main goal is to deliver a good final product.
- Reinvent the wheel to learn. Don't reinvent it for production.
- Don't worry about people who say you're not a real developer if you work on top of other software. You don't have to built a OS kernel to be considered a developer.
- Don't worry about coding challenges if you're not able to do them as quickly as others or even can' solve them. That's a very specific task that requires a lot of training and doesn't translate into being a better developer.
- You'll deal with people, sometimes with very arrogant people. None of us like to be criticized for our code, some take it like a personal attack, but we all have to learn to deal with it. Sometimes we write dumb code, sometimes it just can be improved.
- You're not better than the guy next to you, no matter if you have an university degree and they don't are self-taught.
By the time you are already interviewing, it can be too late to start leetcoding. Unless you're a genius who has a natural knack for this kind of stuff, or are a networking savant that has a knack for finding the rare, good companies that don't hire via leetcode interviews.
When you get a job this behavior will be inverted. You'll know how to write software but you'll have to spend more time learning the domain.
You will face obstacles, problems, bugs, disbelievers, etc. The only way to succeed it to keep at it. You won't believe you can do it... until you do it.
One step at a time. Next thing? It's ten years later and your a senior developer who everyone looks up too.
You are not smarter than others, your code does and will have bugs and design problems, you documentation will suck, you will need ways to debug tricky bugs, the dev language you are best at is sometimes not the best for the task, you can't work more hours than others and you still need a lot of time to learn new things.
If you are naturally really good with computers and can already program, make sure you learn to work with other people. There is, happily, quite a lot of info out there to help borderline autistic types (like me) learn to come across like a normal person. I can provide more info if anyone needs it.
Otherwise, I would focus on making as much money as quickly as possible so you can get out once you realize the toll it is taking on you. It sucks to be trapped in a high-stress, average paying job, with no alternatives and a family to support.
It's a bit dated and somewhat sexist but has a lot of helpful advice - I wish I had read it when I started my career.
I offer this after a (student) friend said "I don't know if I can make a career of it cos I hate Java: do I really have to?". He was so relieved when I explained that his enthusiasm and enjoyment affords him to avoid whatever doesn't resonate.
You can pretty much learn the job and be f-ing done for the rest of your life, more or less.
Otherwise, be ready to be forced to re-learn stuff every two years or so, because of the new trend/framework/language/craze.
Software is an interative process. Sometimes it can take 5+ draft versions before you produce high quality code.
There a good talk on this topic: Writing Software by David Heinemeier Hansson 
If you're short on time, you can skip to the highlight here: 
Lots of people have mentioned how important it is that you communicate, and equally important is, you need to find other people who communicate well and willingly! Its incredibly hard to teach yourself everything, and even if you attempt to teach yourself what you dont know, well timed feedback from another person can save you hours. Same with imposter syndrome, working with good people helps mitigate your self-doubt. Get feedback faster and spend last time thrashing (ie painfully learning) the basics.
It's not necessarily easy to get a job. Don't set expectations too high, and then it's a bit easier. Don't even expect to get invited to the high expectation places (e.g. FAANG), even if you think you followed the right path. My path was: bachelor information science + master computer science (security/multimedia) + internships + TA jobs in programming + 1 year iOS programming + 1 year web development. I am still looking after 2 years. Now companies value me less due to the lack of experience (about 1.4 years unaccountable).
The best job opportunities I've gotten by far is through my friends or people that liked me. I got most of them when I was studying. 2 strategies here: be more likeable, or relentlessly meet as many people as you can (ensure high throughput) and let the people that like you stick to you and discuss business with them. In my experience, both are hard to do since meeting people takes time (out of your job search and keeping skills up to date).
I used to be a coding bootcamp instructor, and the irony is that the students who I used to train have far better positions in me. Some of them still look up to me (while my confidence has taken a big hit) and have invited me to become a senior developer at their company. It's quite funny, because most companies nowadays have trouble to take me on as a medior or even a junior. I don't claim to be a senior or junior. What I will claim, titles are nonsensical because they aren't standardized.
If you happen to go down my path, it will take a toll on your mental health and your sanity. Here is how to stay (somewhat) sane:
* Keep challenging yourself in coding projects, no matter how many companies reject you, keep pushing yourself. The more fun part is to do this with friends.
* Keep teaching people how to code when you know they can learn something from you.
* Keep all other stuff that you have going on in your life rolling (e.g. relationships, hobbies, etc.).
* Keep your costs to an absolute minimum, don't be afraid to stay with your family if you can. You can't use the extra added financial stress.
* If you can't stay with your family or keep your costs down, then lower your expectations and take any job, preferably in IT. Keep looking for a better job. Stay at your new job for 6 months at a minimum. Do your utmost best to kick ass at your new job.
* When you happen to have friends in desirable software positions (I have that since quite recently), apply to their places and ask them to relay what everyone is thinking to you. So far, this is the only way I have been able to get good feedback on my resume letter and motivation letters. The world will be grateful for it (without knowing it) because my resume and motivation letters are now 4 times shorter. This comment is longer than both of them combined.
* Try to stay positive and be careful with showing this form of vulnerability to friends or people on the internet, do so selectively. In my experience, people find stuff like this tough to read and can't handle it too well.
I hope it helps.