cntainer

Totally agree, but this is something hard to grasp for many people.

What's also important is to realize the external constraints. You should always plan to allow a couple of failures before reaching the end of the rope instead of going all in in the first try.

Taking your example if I can only do the task 3 times (for whatever reason: budget, etc) then my chances for success are a lot lower compared to a competitor who can play the game longer.

EDIT: Also it's important to learn and internalize that knowledge after each try. In most cases you can't do the same thing each time and expect a different outcome.

> Working hard while thinking hard and taking risks has made me wealthy

I'm sure there are plenty of people who did the same and failed.

There are always many factors to consider but I would say the key one is luck. With a bit of luck you can easily miss one of the others (working hard for example) and still become successful.

Peopleware: Productive Projects and Teams

https://www.goodreads.com/book/show/67825.Peopleware

Happy and healthy teams result in productive teams, who would have thought :)

Some of my best work was done during 40 hours weeks or less. Whenever I break that rule the end result suffers because I lose creativity and focus.

It's ok to do the occasional extra time when you're really engrossed in what you're doing, but overwork has long-term negative effects.

In general the people being lead do realize they have a good leader/manager after some time, even if they tend to underestimate the effort needed to provide that level of leadership.

I was that guy that had a great manager in the beginning of my career for 2 years. At the time I was thinking he's a good guy but not great. Only later (+5 years) did I realize what a great manager he was and what an impact he actually had on my career.

But you're right, the biggest risk I've seen for this kind of leader is how upper management perceives you. Not a huge risk though, as in most companies upper management ranks leaders/managers like this:

1. people obey and acclaim him -> best leader

2. people barely know that he exists, but good things just seem to happen in his teams -> ok leader. "He's lucky to have a great team" - Average Joe CEO

3. people despise him -> bad leader

Instead, if your company ranks 2-1-3 then you're lucky to be working for a great company, but if your company ranks 1-3-2 then run for the hills.

From what I've seen number 2 gives the best results overall with very positive long-term effects on the team, but it takes another good manager to recognize and appreciate that. So you might end up frustrated if you're expecting recognition and accolades from someone like Average Joe CEO that I quoted above.

In the wild I think a continuous balancing act between 1 & 2 works best. You're probably a saint if you can pull number 2 all the time while also keeping your sanity. :)

This!

I've been in the industry for 10+ years moving through the ranks in all kinds of setups, from developer to senior management, and I think you expressed nicely the gist of it:

The irony is that you don't really notice a great manager. Their job seems like a walk through the park, and you have a "I could do that job easily" feeling

Very similar to what you're saying is this quote from Laozi, a personal favorite:

A leader is best when people barely know that he exists, not so good when people obey and acclaim him, worst when they despise him. Fail to honor people, They fail to honor you. But of a good leader, who talks little, when his work is done, his aims fulfilled, they will all say, "We did this ourselves."

It's a tough path to walk on, as you have to let go of your ego, but seeing the team succeed always makes up for it.

I agree with your costs argument, but my point is you can rarely blame the language. If we bring the frameworks in the discussion it gets even more complicated.

If you build a Rails or Laravel app in the same way you would build a Java app, the Rails/Laravel app will be dead slow. And I've seen that happen. But if you know what you're doing you with Rails/Laravel it will be a long time before you say: we should rewrite this in Go/Rust/Erlang.

The main criteria for me when choosing a tool for the job is: how well does the team know the tool? can they use it at full potential?

I've been involved in java project with 20k monthly cloud costs. Most of the workload is handled in the background by consumers that pull messages from RabbitMQ. I'm pretty sure I could rebuild that with any language while actually reducing the costs because the bottleneck is not the code but the architecture. Would it matter if I would rewrite it in Java instead pf Python or Ruby, in terms of performance, yes, if we need to consider other things, like speed of development, etc it gets complicated again. :)

It's usually fast for me with the occasional slow down.

From experience (did some code contributions to gitlab) when you work a lot with the filesystem, as is the case for platforms hosting git repos, you will have performance issues related to that, regardless of the programming language.

we host gitlab at my company for internal use, just switching from SSDs to HDDs made a big difference in terms of response time for big actions like opening a merge request, etc

I'm sure there are apps in the wild that get to that level of optimization where you need to decide on a different language. But what I've usually seen is you just slice that part out into a service and only rewrite that part.

I think stripe and others are basically doing this if they do hit the limits of ruby in very performance intensive workloads.

I haven't touched wordpress in 8 years, but with old codebases you always inherit a lot of bad design decisions that always have an impact on general performance.

Maybe the wordpress guys have done a great job in rewriting the internals and cleaning things up in the last years, I wouldn't know, I don't follow their progress.

Lol, I agree their packaging looks a bit different but the contents of the package are basically the same.

Working with both Laravel and Rails will make it clearer that they try to follow the same principles of convention over configuration and programmer happiness :).

Well if 80% of the web was running on ruby there wouldn't be any difference.

Most people don't understand that 99% of performance issues are not caused by language performance but by bad architecture and bad developers.

Always choose the best tool for the job, you rarely get to that scale and quality of software design that only the raw language performance is left to be optimized :)

Well, github, just to name one:). Also shopify, digital ocean, stripe. I also worked on a large ruby app that was faster than another large Java app. Keep is mind that all these platforms handle a great deal of requests at any given time, so we're not talking simple web apps.

In my experience bad software design, bad DB design and bad developers are the major cause for performance issues, you rarely get to that level of polish with your app that the difference between different languages really matters.

At micro-bench level PHP always beats ruby pr python, but most apps have performance issues without ever getting to that level.

My funnies experience was with a java team that where baffled why their app is slow. I told them it looks like they have a huge bottleneck on the DB, their answer: "Yeah but it's java, it should be fast"

Agreed, Laravel provides the best dev experience in the PHP world.

The funny thing is that Laravel basically took the Ruby on Rails philosophy and applied it to PHP. Just looking at their site it's clear they have a very similar vision: simple, fast and fun. One can always find differences but the basic principles are the same.

IMO this is great kudos to the Laravel guys, whatever language I use I always look for the tooling that follows the KISS principle. In PHP you have Laravel, in Java/SCala you have PLay, etc.

I need to add that, because of the job, I did a lot of PHP, Ruby, Java, Javascript with many different frameworks and I can say that Rails is still the best for me when it comes to dev experience if you need to move fast. Laravel has come a long way but it's still not at the same level of maturity in terms of tooling and ecosystem. As a bonus with Rails you use Ruby which is designed for programmer productivity and fun.

Anyway, whatever language/framework you use just keep it simple, that's the most important decision you can make for the health of your project.

Yep there is experimental support for native windows containers. (Not sure it it's still experimental as things move really fast in this space)

As I remember you couldn't have windows and linux containers running at the same time so you needed to flip a switch in the docker config to chose one.

I general I'm a linux guy but it would be really cool if they can get to a point in which you can run both windows and linux containers at the same time.

Not really missing anything, it's just that on macOS you actually need a vm to run docker. Docker for mac uses HyperKit VM and starts docker containers inside it.

It's mostly the same on windows (you needed hyper-v or virtualbox to run docker) but they are making efforts to run containers natively. Not sure how far they got with that.

In the end if you want the best performance with minimum resource usage you need a Linux OS