Veteran engineers (10 yrs exp+) advice needed

. Don't do a good job; only seek to make sure ppl (managers and co-workers) are happy with the job you do.

. Do what's best for you (not necessarily the organization). Aka Resume Oriented Architecture. Aka ROA for the best ROI.

. View being employed as a business. Would you ever start a business to sell to one client? Always be looking for the next client.

. Never document anything. Sadly, the more obscure language/tech/code/artefact you emit, the harder it is to get rid of you. I inherited a whole team that had all the router/switch/etc passwords in their heads "for security reasons". They could not be fired, even for coming in at 10.30am and leaving at 3.30pm, constantly missing meetings, etc.

. Hire someone to replace you once you've built an inscrutable system. You can't get promoted if you still do everything and you can't do nothing (manage) if there are things to do.

. Save and invest often. If you do, by the time someone competent is in a position to see how bad a job you did and bring the hammer down on you, you'll have enough to take up woodworking and occasionally chuckle to yourself thinking about how anyone would ever right the trail of destruction you've left.

. Never tell anyone these things. ;>

/sarcasm

Along with that, the company I work for has been good to me through the years. I've enjoyed working with my co-workers and the projects I work on. While I may be able to make more working for another company, I do think that the atmosphere and ethos of a company bring a certain amount of value that I would be trading off. I may be wrong, but I have no reason to think otherwise at this point.

I've always been self-taught, and always tried to be working on something on the side, so I believe that has allowed me to keep up with changes and try new things to scratch my itch of not being complacent.

When I first started working at my full-time job, I was the only developer working on my project and was entrusted with choosing the stack I felt could get the job done. It felt very early start-up in that sense. Shortly after that, I began working on another product that I'm still working on today, and wrote the main components in Go and some back office parts in PHP. To help support me being the sole dev, we had a few other devs come in and rewrite the majority of the components in Java because back in 2013, Go wasn't as widely used as it was today.

I'm thankful that for the most part I've always been able to choose the tech or libraries I want to work with, within reason. I try not to push it too much, for example we use MySQL and Redis primarily for data storage and transient storage, but part of our app does use Mongo and that was a direct result of me trying to hop on the bandwagon early on that I now do regret because Mongo provides us no benefit over MySQL.

If I do want to use some obscure tech to test out, then I'll use it for my own projects. If I feel comfortable enough then I'll use that for my client projects as well. Only if it's something I've battle tested will I see if I can use it in my primary job.

For the first time in 5+ years I am not developing a client side-project in PHP or Go, I'll be using Ruby on Rails, because I'm at the point that the stability of the toolset and my productivity outweigh any performance gains that may be had with Go, and these projects are primarily back office that won't be doing a ton of data crunching or have more than a dozen users using it at a single point in time.

Since you asked about career moves, the best things I did:

- Learned relational databases and SQL in depth. Many applications (and almost all business applications) are built around databases. Databases tend to have more business value and longer lifespans than application code.

- Learned Unix/Linux and the command line tools. I can get a lot done with simple stable tools that come out of the box when other “engineers” are writing piles of code to get the same job done.

- Get along with other people, learn from them, listen and pay attention. I always want to learn how the business works and what people who aren’t programmers do. That pays off in the form of contacts in various industries and positions who may give me work later. Connections count for a lot, more than languages and tools (now called “stacks”) in my experience.

- Domain expertise. Rather than think of myself as a “C programmer” or “PHP programmer” I present myself as someone who can understand business requirements and add value. Knowing how logistics or retail or finance works has more long-term career value than mastering a programming language.

  * working in a consulting shop (for breadth of experience)
  * working in a big company (exposure to scale I can't get any other way, though I didn't stick around long enough, tbh)
  * working with a product for years and years. makes you think about ways to help future you in a way that consulting won't.
  * blogging about problems I found interesting. to write a description of a problem is to begin to truly understand it.
  * speaking. doesn't have to be at a bigname conf, even at a meetup will force you to learn.
  * founding a startup. not for everyone, but super helpful to me in having user empathy, thinking about business process as well as code, GSD
  * doing a stint as a technical trainer. really improved my grasp of the technology.