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.
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.