miguel laginha blogs here

This is why books are necessary. Charlie Munger loved to quote a line from an old machine tool ad: “The man who needs a new machine tool and hasn’t purchased it yet is already paying for it.” You’re already paying for the knowledge you need but don’t have yet.

I keep reading books “for beginners” whenever I can. I read all sorts of books - even though 2016 has been a terrible reading year, something I very much want to change in 2017 - and that includes advanced technical books as well, but I find myself constantly “chasing” change. You see, the basics I learned when I first started working are very different from basics today because things change a lot. Sure, some of the principles may stay the same, but may reflect differently on the job and in life in general.

Programmer Anarchy is a post­Agile process that focuses on empowering programmers by eliminating roles that interfere with domain knowledge and assumption of day­to­day decisions by the programmers. Originally conceived in a startup environment at Forward Internet Group in London, Programmer Anarchy is now being implemented in a traditional IT shop for an established company: MailOnline, the online newspaper arm of the Daily Mail of London. This discussion will talk about the introduction of Anarchy into a Scrum shop, the training, the transition of roles, and the redesign of HR roles.

Since I’m in between jobs, I’ve regularly been visiting some of the most known job boards online looking for interesting projects out there. Like most people, I usually immediately skim read information about the product, technical challenges, and team, looking for a potential job apply for. But it’s not until I read the experience requirements that I assess (and often dismiss) the opportunity.

Nowadays company positions requirements are crazy inflated. A few years ago, at least in Portugal, everyone looked for great junior talent with an excessive amount of experience (as if the junior guy had been working since pre-school). Now it’s pretty much the opposite: 3 years of some frontend framework, 6-8 years of some backend technology, 4 years of dealing with some database. Are these legitimate expectations OR am I seriously behind regarding the work that I do and how much I learn to keep up? It feels I should have been working 24h a day for the last ten years.

I mean, sure, one might have been working for three years in some project dealing with a couple of technologies, but what exactly is the difference between having one year and three years of experience? Surely by the end of the first year, you got an excellent grasp of how it works and how it can be used, right? Are those two extra years that important regarding **proficiency**?

If you’re using the same technology for 15 years, you might say that’s your experience, but your skill probably stopped evolving after a short time. Similarly, if you’ve been working three years with some modern framework, you’ve probably plateaued out already, not to mention how obsolete it probably is already.

Generally speaking, I think this works like this: you accumulate experience continuously and linearly, but you’re not always learning at the same pace. Eventually, you plateau out because the experience you’re getting isn’t making you learn new things. Proficiency stalls, experience doesn’t, wouldn’t you agree?

Does this make any sense?

What good management is like.

Just finished reading “Leaders Eat Last: Why Some Teams Pull Together and Others Don’t” and rated it 5 stars on goodreads.

One of the most important lessons I kept throughout the years.

A kind of follow-up to a previous post.

I can definitely relate to a lot of these, both in the present (as software engineer) and in the past (as tech lead / manager).

«Most of us get so hung up on how we think the world should work that we can't see how it does.»

Understanding this was key to taking control of my life a few years back.