havkom

Yes. And when it comes to having multiple people and teams involved and starting work it may become costly to reverse an otherwise reversible decision.

Really enjoyed this piece.

Now I better understand:

make clean && make

(Regarding the mtimes link in the first paragraph)

What a nightmare to be an executive at Tesla. Elon micromanaging your staff.

Probably together with Sweden, possibly on monday.

The company was lucky to have someone like you that could actually sort out real problems efficiently. I would bring up this story when negotiating for a raise.

I agree (with some reservations, see my other reply to my post)

My approach so far is to be very very allowing —- until any failure becomes apparent and it can “naturally be discussed” (or it causes problems with colleagues in the group).

This can be quite stressful though — I do not think the people reporting to me understands how much energy is spent as a manager negotiating with others in order to give the team and team members the most space/maneuverability that is possible.

As an engineering manager myself I concur with all the points.

Some of them are difficult though, for example:

“optimize the dual objectives of delivering value to the organization and giving individuals problems that build their skillset, impact, satisfaction, …”

and

“ Managers with excellent execution skills and deep domain knowledge must resist the urge to present solutions to their reports.”

To what extent should one allow suboptimal solutions, failure or allow employees to do things inefficiently with their “favorite tech stack” (in cases where it does not add business value) ?

I would suggest that one tries to limit dependancies. The entire node ecosystem contraviene this so maybe people should not use it.

Exactly my thought!

Knowing how to search in a large code base is a large part of this and could be included in what ”good at reading code” means.

This skill is what differentiates really good developers from not so good developers (that may wrongly believe themselves they are good):

How good are you at reading code, finding out how smaller parts work in a larger system and understanding the context&domain is a large part in how good you are.

Not so good developers, when they are not so good at this, often start blaming the system and people who have worked on it.

Not so good developers may however be able to handle smaller systems (in particular ones written in their favorite tech stack), and this experience leads them to erroneously believe they are good.

A tip from recent experience with GitHub: Don’t rely _solely_ on GitHub for your work.

Have not used gdb for a while but I think a good gdb tip is that you can evaluate functions with the print p command:

> p myfunction()

The most compatible technique is long polling (with a re-established connection after X seconds if no event). Works suprisingly well in many cases and is not blocket by any proxies.

Good ability to read code is what separates agood developer from not that good.

A good developer can work on any project. A not so good developer can only work in smaller not so complex projects written in their favorite framework with certain patterns.

A good developer can solve any task. A not so good developer says that the task (or the whole project) is wrong if is too difficult to do in their favorite framework or with their favorite pattern.

Typical supoptimization that is probably suggested by some management consultant that has been hired by some department by an incompetent manager that him/herself is struggling (due to incompetence).

As an engineering manager I tried to replace daily stand up meetings with a “drop a couple of lines in the team chat daily”. I think it worked great and a lot of more relevant information was brought forward and lead to more productive co-operation between team members.

However, some team members thought this was “wrong” and “not how agile should work” so eventually after continuing complaining I had to reinstate/allow these stand-ups again…

Great skill to not always having to be right (even when you are). This helps you alot when you want to acctually accomplish or change something - which is something you usually want to do when you have alot of knowledge.

Maybe. But I was commenting on the real hospitalization numbers and implied vaccine protection from comparing the ratios 1) hospitilized vaccinated vs hospitilized non-vaccinated [the linked spear sheet] and 2) vaccinated in relevant age brackets vs non-vaccinated in relevant age brackets.

”Now, with Delta, it looks like the figures are 64%, 93% and 93% according to Israel, and 79% for symptomatic infection and 96% hospitalization according to the UK.”

I doubt these will turn out to be correct numbers. Looking at recent week’s data in Israel possibly paints another picture (keep in mind while parsing the numbers that there are plentiful many more vaccinated in the population than not in the age groups that gets hospitalized): https://docs.google.com/spreadsheets/u/0/d/1kiOrQxOtBg0__IoL...

Nevertheless, it is clear that vaccination helps and is important, but I have doubts about 90+% protection from hospitalization.

I have encountered co-workers who bring a clear negative contribution to the team. I am not taking of not making enough of a value for the company for what they are paid but rather damaging the company even if they were paid nothing. These people have all been eventually let go by the different companies I have worked for.

Azure’s support is great! I am not surprised they quickly helped out.

First time I contacted them I was not hoping for much. But after a few contacts I realize they must be one of the best support orgs in the world.

They can quickly help out with anything from very trivial questions to helping out with very difficult faults, and do this without having to be harassed about escalating my tickets. Outstanding.

Maybe use GraphQL instead of inventing a new query language?

Like setting up rules enforcing pull requests to merge to production branch and having all PR needed to be reviewed by at least 2 ppl with no escape mechanism in place..

Great until something goes terrible wrong and some absolute critical bug has to be fixed when you are on-call alone on a weekend.

Never disallow escape hatches. You may not need both your arms in your everyday job or in your life in the ideal case, but keep cool and wait going to the doctor for an amputation just in case.

Especially nowadays when ppl learn some specific JavaScript framework, think they know how to best do stuff (because the framework is hyped), and then the learning curve stagnates.

Solved an “almost impossible” today with “0 hits on Google”. Felt awesome - this is why I like programming.

Here is Swedish public service television company’s teletext service: https://www.svt.se/text-tv/100

The workload of managers have probably increased as well. This may not be sustainable for all organizations?

One thing that managers generally does not like is staff that does not “fall in line” and create issues for them that they have to deal with. I would therefor not mention for example having emailed VP:s about issues or highlighting bypass functionality in systems (if your previous job description did not include to highlight this).

From a managers perspective in the example, they are trying to run an operation of good support. They have to comply with different laws and have a solution “that works”. They may not appreciate that someone in the staff highlights “flaws”. If someone highlight flaws of this type anyways:

1) if highlighted by a staff member may have to be addressed. In particular from a staff member that emails VPs. Some point in time, possibly after a difficult process, legal may have ticked this off. The manager may not be happy to have to revisit this question again.

2) It may be difficult to address for the manager (request new support services software? Get an opinion from legal? - may be a large project)

3) disrupts the main goal of the manager of providing good support services.