1. Once I felt like I had mastered a language I’d start learning another. The techniques in a new language would teach me things to take back to my primary language. Functional Programming for instance was great at teaching the value of simple functions. Prior to that I’d put everything in Objects which had implicit state leading to sometimes hard to reason about code. Also Objects still have a place for making easy to reason about code.

2. If I saw a new technology I thought would be useful I’d try it on my own before trying to incorporate at work.

3. Downtime at work was used to learn more programming by working on projects that would help make my life easier at work. Bash scripts, improved builds, improved developer tooling

4. In the corporate world. Learn the soft skills, when to talk when to be quiet. How to brag about your work appropriatly to get those raises.

5. Constant learning. Programming changes fast. If I stuck to what I started with my skills would be far out of date and my job selections would be slim.

I should start by saying I was a middle manager in a large corporation. This may be a different experience in smaller settings.

I think the transition to manager didn’t live up to expectations for me. I knew I would be committing less code and helping clear roadblocks. What I didn’t expect was the bureaucratic catastrophe that is HR and upper management. Often I wasn’t clearing roadblocks as much as insulating my team from terrible knee jerk reactions from above. In example productivity is down let’s bring everyone into the office post Covid. Productivity was not down for my team but going back was the start of it. My top level performers I struggled to hang on to due to HR in acting strict requirements for promotions. Senior needed 7 years and other random rules. That coupled with some not wanting to come in. I remember the most impactful being losing a 4 yr experience programmer who outperformed every senior I had due to those rules.

There were parts I enjoyed. Helping the juniors grow and the surprises I’d get from that. I learned very quickly that a devs initial skill coming in from college or life transitions was not a good way of judging their maximal. I’d have devs come in that I thought no way they’d be a top performer to a few years later being shocked at how good they were and how they flew past their peers. It made the inevitable loss of them more painful. I knew my shooting stars would see better pay and advancement elsewhere.

I really had no problem with the transition from contributing to relying on others. I missed contributing and was good at it but I knew it wasn’t my role. I knew from past experience a manager didn’t know enough about the day to day code to give fine grained suggestions on how to write code.

I was a fast track developer. Was senior in 4 years but involved a few job hops. Many companies require x years to get to senior but for some reason that goes out the window for new hires with talent.

It wasn’t until managing people that it became obvious why I fast tracked and others don’t. There is a huge difference in our industry. I like to use the analogy of sports. You have multiple levels recreational, college, and professional. As you get better you move up but there’s a gate to moving up that some never achieve maybe genetics maybe effort. The difference is it’s all mixed up in programming there’s no divisions you can have a 15 year programmer stuck at rec level and he’s programming with a 3 year college level athlete that’s running absolute circles around him. The productivity gap is huge. If you manage to get a pro level programmer on your team he’ll make the other 3 rec level programmers look like a waste of money. It’s like the elite runners who complete a marathon in around 2 and a half hours and it’ll be another 4 to 6 hours before the slowest finish. That same gap is in the programming world it’s just not as obvious.

So all that said my advice is to find what your skill is. If you seem to be outperforming your elder peers you’ll benefit from aggressively asking for raises and promotions as well as making a job hop every few years if HR stagnates your pay for the dreaded “years of experience” excuse.

You might also eventually get promoted to a point where you find yourself not excelling. This was my experience in management. I became a manager too young or maybe I’m not built for it. After a few years hating management I went back to programming as a consultant because I realized I was on that upper side of the skill differential, I enjoyed coding and now armed with that knowledge of where I am I can ask for even higher amounts of pay exceeding management pay.

Oh totally seen it work myself but I don’t know that it was agile that worked as much as they had a kickass team.

Some teams just jive well. They communicate, they know what each other is doing, and they can plan with minimal waste. And when it’s successful that’s across all roles not just the devs.

In my opinion those teams would have succeeded in waterfall, kanban or their own home brewed strategy as well.

Oh totally seen it work myself but I don’t know that it was agile that worked as much as they had a kickass team.

Some teams just jive well. They communicate, they know what each other is doing, and they can plan with minimal waste. And when it’s successful that’s across all roles not just the devs.

In my opinion those teams would have succeeded in waterfall, kanban or their own home brewed strategy as well.

Interesting you prioritized pointing out on time delivery as opposed to maximum value.

Hits a sore spot, I’ve delivered a lot of useless stuff on time with agile teams. We could have been useless even faster without the meetings.

Say it in standup with management in the room and watch the response

Agile in it’s current implementation with excessive meetings wastes more time than the mistakes it tries to avoid.

I give typescript running a decent shot of being a major force in backend APIs. There’s a draw to being able to code the same language on front and backend. It’s got a stronger type system than Java in strict mode as well.

It also has quick boot time which can help in cloud functions that may eventually become the preferred method of APIs. No server or os to maintain and they are close to the customers location

Nah not equivalent. I’ve worked on rust for side projects and a few lower level networking things. Hard to get equivalent experience because my regular job is probably 60% frontend webapps.

Typescript being everywhere with strong libraries for even brand new tech is why I think it’s a great general purpose language. Whatever new product I’m integrating with always has a JS or TS library.

You don’t have to convince me Rust is a better language in so far as what it provides the programmer to make a working and correct program but I’d argue it’s not the best general purpose yet for many reasons that go beyond the design of the language and engineering. Such as availability, clients who pay me for code, and third party libraries

Probably should clarify. I think there are better languages in design and safety for backend.

However when it comes to a language you can pick up and crank out code for JS/TS is hard to beat. There’s libraries for everything and if your a full stack dev your probably really familiar with all the ends and outs.

If I have time and I want to make a solidly engineered product Rust is a better option. But often I’m pressed for time and TS can make a solid enough and performant enough product.

Typescript has many shortcomings. About every language does. But it’s an undeniable very strong benefit that you can code the front and backend with it easily. It runs everywhere. It’s reasonably fast, for aws lambdas I found it had really good cold start time. I suspect because node is built on V8 which is highly optimized to get code running asap.

That accessibility and versatility makes it in my opinion the best general purpose language right now.

Typescript. Runs everywhere. Very active community. It’s the modern day Java.