miguel laginha blogs here

(mainly) geekish jibber-jabber

[brecke]

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.

This is why I can’t get enough of Farnam Street blog.

[brecke]

Fundamentals

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.

When you’re working in IT everything moves so quickly there is no guarantee the technological ground you’re firmly standing on won’t be obsolete tomorrow, and all one can do is to run as fast as one can to stay in the same place. And that includes revisiting the basics as well.

[brecke]

Freedom is great, but «constraints can guide you towards better design». What an amazing talk.

[brecke]

GOTO 2014 • Implementing Programmer Anarchy • Fred George

This presentation was recorded at GOTO Chicago 2014 http://gotochgo.com Fred George - Co-Founder of Outpace Systems, Programmer Anarchy ABSTRACT Programmer A...

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.

Being somewhat of a libertarian, I’ve been looking for this my whole life. Amazing stuff.

[brecke]

A friend of mine shared this link in his twitter timeline and it is full of wisdom. Read it now.

[brecke]

Couldn’t have said it better myself.

[brecke]

Proficiency vs experience

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?

Why is everyone asking for experience instead of proficiency? What am I missing?

[brecke]

Interesting read. It makes you wonder whether you’re in the right at the right time.

[brecke]

What good management is like.

PS. I also suffer from the “imposter syndrome” o_O

[brecke]

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

There’s so much fantastic material in the book that makes any attempt to review it rather overwhelming so I’ll just leave you with the best quotes on goodreads and the personal recommendation to read it plus the guarantee you’ll learn a great deal on the topic.

[brecke]

Just in case you like droning ambient music while coding.

[brecke]

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

Also, can’t believe it’s from 2008!

[brecke]

A kind of follow-up to a previous post.

I can definitely relate to some of those points, especially those in the opportunities category. We software engineers are a privileged kind, aren’t we?

[brecke]

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 these issues belong to the “don’t kill you, but make you wanna kill yourself" category and they all take their toll eventually.

[brecke]

«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.

It’s a tremendous (and continuous) exercise of empathy to see things as they are instead of how they should be, but it’s self-liberating one too. Also, it might just be the leap in your life that turns causes into effects, blame into responsibility or idleness into action. There is no going back after that.

[brecke]

A reminder of how important it is to be unreasonable.

[brecke]

Throughout the years I’ve built and perfected my own labelling composition strategy which is very similar to this one, so I guess that makes me sane somehow.