[dougbarrett]

I've been in my current role for nearly 9 years, working in the field for 12+. I'd say that the one piece of advice is to not get stuck to a certain stack if you have the authority to make those decisions.

You're definitely going to make the wrong decisions about the stack you choose, or the way you design elements of your code, but that is how you learn.

Good problems to have, like scaling to thousands of concurrent requests, have been the greatest opportunities to learn. You may not get the answers right away, but they will come.

Before I get comfortable with learning any new language, look into the best practices for caching, or how easily that is handled. Your ability to know how and when to cache whether it's in memory if the language you use supports that, or through memcached/redis is going to make it less likely that you're going to need to do a complete rewrite in the future.

I first started programming 20+ years ago before I was 10 years old, with Visual Basic and the demo. Eventually moving to access, and PHP in the early 2000's in my later years in high school. Today, some of the larger apps I've written have been written in Go. Lately in the last few weeks, I've really come to love Ruby/Ruby on Rails, and for apps that I don't need to scale, that is going to be my go-to language for my own projects and client projects.

Would I suggest we rewrite everything or utilize Rails in my day job? Not a chance, because 1) my productivity is not worth it and 2) it's not the right tool for the job. Maybe if we had to write some back office software I'd recommend it, or I'd use Sinatra for a basic API/demo.

[strikelaserclaw]

i see people around me jumping ship every two years for various reasons, but you've been with a company for almost 10 years, do you think that steadiness has helped you become a better engineer or has detracted from helping you gain experiences?

[dougbarrett]

I think my position is unique to others. A year after I started, my wife and I had our first child, so ensuring we had a stable and steady stream of income was my priority above all else.

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.