Software engineering is about state management and team dynamics.
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.
- Always be learning. Take half an hour each day to read a chapter of a text book, listen to a programming podcast, read some development blogs. THe time will very quickly add up and is easier to do than sitting down to study 3.5 hours once a week
- 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
Your job is to deal with customer requirements (i.e. listening to people), and translate those into code other engineers (communicating with people) need to maintain, on a priority/schedule your management (also people), create to deliver business value. This is a people business, whether you like it or not. Develop those skills.
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.
> Your job is to deal with customer requirements (i.e. listening to people), and translate those into code other engineers (communicating with people) need to maintain, on a priority/schedule your management (also people), create to deliver business value. This is a people business, whether you like it or not. Develop those skills.
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.
>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%.
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 burn yourself out. It's just a job, not your identity. Put in your 40 hours then do something else. You might not enjoy programming for money as much as programming for fun, so you should also develop other hobbies.
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.
Exactly. There seems to be such a push in the industry to be "passionate", which translates into working extra hours and working on open source in your free time
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
Don't let your ego become entangled with your work. If you work for someone else, always remember that you're hired help and they have the final say. It doesn't matter how small or flat the company is, unless you own it, you work at the behest of another. You don't need to agree with decisions. You can think they are disastrous or completely misguided but if the CEO or tech lead wants to pursue that course, that's their prerogative.
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.
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.
Focus on business value, avoid being seen as an expense. Many software engineers believe they're the most critical part of a company while higher-ups actually usually see us as expensive code-monkeys. Don't get me wrong: I'm not telling you not to work in IT security if your true passion is here, but keep in mind you'll most likely perceived as useless if everything goes well, and incompetent if something goes wrong. You'll most likely be among the first engineers to be let go in case of trouble because infosec is simply not that valued by businesses.
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.
Whenever you join a new team, look at the work everyone is doing and try to identify stuff that isn't getting done as well as it should, or where the team is lacking skills, and aim to own that area. Learn what you can from the most skilled and able personnel for sure, but it's the team weak spots that you can make the biggest personal impact on.
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.
Read the book Apprenticeship Patterns (which is available for free online here: https://www.oreilly.com/library/view/apprenticeship-patterns...). It contains a set of patterns that you can apply to figure out what to do in different situations through your career. I was quite far into my career when I read it and I wish I'd done so earlier because it helped me turn my career around. The book has a strong emphasis on finding the learning opportunities in different situations and that was key for me: never stop learning.
One leetcode problem a day keeps unemployment away (and helps career advancement).
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.
If you're in a place with people you like, with sane management, and OK or better pay, do not be in a hurry to move to the next job. Positions with those ingredients are not real easy to find, and it stinks to be in a job without one or more of those.
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.
- Never stop learning. Not only about tech, about everything.
- 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.
Assuming you have already landed a first job and are starting out working in the industry. If you don't have a first job yet, ignore this. :-)
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.
"Ask for help if you get stuck" absolutely right! But write down the answer for later reference, try (with the strongest possible effort) not to ask the same question twice. Or if you have to, you can also point to the previous solution and short addressing why/that this solution is not working anymore.
Be very wary of always chasing the latest and greatest. You can easily spend a decade or two pursuing the latest trends. Be open to new technology, but pick something and stick with it until you master it. You should probably pick something that is being used by many, e.g. Python or Javascript.
Your learning process should mainly consist of reading and writing code.
Don't be one of those arrogant guys who thinks he knows everything better. A lot of software engineering wisdom seems to come purely with experience. By all means, offer your perspective! But also take the old grey beards seriously. They have seen a lot of things before.
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.
If the comment made here "It's just a job, not your identity. Put in your 40 hours then do something else.", then look at a larger company. You'll be less likely to "make a difference", but you'll be less likely (not impossible, but less likely) to be fired or laid off. You'll get insurance, time off, some flexible time to go to kid's games. You won't be Dorsey or Zuckerberg rich but you won't be working 80-hour weeks for the slim chance of being rich.
Work on a programming side project related to some hobby you already enjoy and know. Being familiar with a topic makes programming easier since you can focus on learning software development instead of the domain.
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.
Stick with it. You'll go through periods of time when something seems super complicated (legacy code, new algorithm, new framework, new language etc.). But just stick with it, you'll figure it out eventually.
If you're naturally extroverted and have a natural way with people, make sure you really enjoy software, otherwise you're going to struggle.
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.
Be humble, a lot of the great advice given here are a direct result of that.
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 doing user interfaces, split the part computing values from the part displaying them. If you are not doing user interfaces that does not apply. What applies in both cases is that automated tests are your friend. In the user interface case the part calculating values needs them most.
There is no place for stress or anxiety in this industry. You either need to find a workplace where stress and anxiety are not tolerated or you need a way in which your work doesn't get to you. Otherwise your career will be very short, if you are on the neurotic side of things.
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.
Don't chase the latest and greatest shiny thing! Focus on mastering the fundamentals, they last far longer. Someone wrote on HN the other day "When in doubt, study maths". You needn't go that far, but I think the principle is sound.
Ignore all popular advices and "influencers" like plague- avoid companies with loose moral compass - especially those say "don't be evil" and "free product"
A programming language is just a tool. Don't dedicate yourself to one language, and learn the practices that transfer to other languages and environments instead.
Improve your communication skills if you have not already improved them. Understanding a set of requirements and what a customer really wants is invaluable.
if the reason you are starting in this industry is because you think software is lots of fun and really interesting;
it's fine to focus on what you enjoy.
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.
This!
Find good coworkers, good team mates, any one who is willing to communicate with you.
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.
This is my experience. I hope it will be useful to you. I am interpreting "starting out" as "finding a new job". It can also mean "starting day 1 on your new job", but I have less to say on that matter.
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.
You only have so much brain energy for the day. Use it wisely. Focus, focus, focus, and INTENSITY! Without these, the software biz is a slippery slope into house slavery.
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.