Link tags: technical

13

Giving your future self a little credit with progressive enhancement - Blog - Pixo | Apps, websites, and software development

We often talk about technical debt — the costs we’ll need to pay in the future when we make short-term compromises. Progressive enhancement is the opposite of that — a sort of technical credit that will make things easier for us in the future.

A good explanation of how progressive enhancement works perfectly with the idea of a minimal viable product:

We focus first on a core experience that delivers what your users are looking for, and then we start adding enhancements that will delight them.

Let’s Not Dumb Down the History of Computer Science | Opinion | Communications of the ACM

I don’t think I agree with Don Knuth’s argument here from a 2014 lecture, but I do like how he sets out his table:

Why do I, as a scientist, get so much out of reading the history of science? Let me count the ways:

  1. To understand the process of discovery—not so much what was discovered, but how it was discovered.
  2. To understand the process of failure.
  3. To celebrate the contributions of many cultures.
  4. Telling historical stories is the best way to teach.
  5. To learn how to cope with life.
  6. To become more familiar with the world, and to know how science fits into the overall history of mankind.

People Problems | CSS-Tricks

I’d maybe simplify this people problem a bit: the codebase is easy to change, but the incentives within a company are not. And yet it’s the incentives that drive what kind of code gets written — what is acceptable, what needs to get fixed, how people work together. In short, we cannot be expected to fix the code without fixing the organization, too.

Responsible JavaScript: Part III – A List Apart

This chimes nicely with my recent post on third-party scripts. Here, Jeremy treats third-party JavaScript at technical debt and outlines some solutions to staying on top of it.

Convenience always has a price, and the web is wracked by our collective preference for it. JavaScript, in particular, is employed in a way that suggests a rapidly increasing tendency to outsource whatever it is that We (the first party) don’t want to do. At times, this is a necessary decision; it makes perfect financial and operational sense in many situations.

But make no mistake, third-party JavaScript is never cheap. It’s a devil’s bargain where vendors seduce you with solutions to your problem, yet conveniently fail to remind you that you have little to no control over the side effects that solution introduces.

A World We Built to Burn | emptywheel

The climate crisis as technical debt:

What we’re dealing with is hundreds of years of something that software world calls technical debt. Technical debt is the shortcuts and trade-offs engineers use to get something done either cheaper or in less time, which inevitably creates the need to fix systems later, often at great cost or difficulty.

Some technical debt is understood up front, some comes from builders being ignorant of the system they are working in. Most of our planet’s infrastructure is mired in huge amounts of technical debt, most of which we didn’t know we were signing up for at the time, some of which we’re just incurring recklessly as we go along, unable to face the scale of the problem and pushing it off on the next generation.

The Technical Debt Myth

In some cases, it’s entirely valid to explore new products and technologies, but in others, our striving for novelty becomes the driving factor for abandoning perfectly suitable solutions under the umbrella of technical debt.

Just because a technology is a few years old and possibly frustrating in some cases doesn’t mean you’re in technical debt. We need to stop projecting our annoyances as pitfalls of technological or design choices.

whiteink — Tech lead: an introduction

A series of posts on the decisions and trade-offs involved in being a tech lead:

I think good tech leads spend a lot of their time somewhere in between the two extremes, adjusting the balance as circumstances demand.

Dealing with Technical & Design Debt - Breakfast Session - Agile Swap Shop (Brighton, England) | Meetup

If you’re a project manager anywhere near Brighton, put this event in your calendar for the morning of May 30th.

ongoing by Tim Bray · Geek Career Paths

Tim Bray lists the options available to a technically-minded person thinking about their career path …but doesn’t mention the option of working at an agency.

Some good long-zoom observations in here:

The bad news that it’s a lot of work. We’re a young pro­fes­sion and we’re still work­ing out our best prac­tices, so the ground keeps chang­ing un­der you; it doesn’t get eas­i­er as the decades go by.

The good news is that it doesn’t get hard­er ei­ther. Once you learn to stop ex­pect­ing your knowl­edge to stay fresh, the pace of in­no­va­tion doesn’t feel to me like it’s much faster (or slow­er) now than it was in 1987 or 1997 or 2007. More good news: The tech­nol­o­gy gets bet­ter. Se­ri­ous­ly, we are so much bet­ter at build­ing soft­ware now than we used to be in any of those oth­er years end­ing in 7.

Technical Credit by Chris Taylor

Riffing on an offhand comment I made about progressive enhancement being a form of “technical credit”, Chris dives deep into what exactly that means. There’s some really great thinking here.

With such a wide array of both expected and unexpected properties of the current technological revolution, building our systems in such a way to both be resilient to potential failures and benefit from unanticipated events surely is a no-brainer.

The Conjoined Triangles of Senior-Level Development - The Frontside

This is relevant to my interests because I think I’m supposed to be a senior developer. Or maybe a technical director. I’m really not sure (job titles suck).

Anyway, I very much appreciate the idea that a technical leadership position isn’t just about technical skills, but also communication and connectedness.

When we boiled down what we’re looking for, we came away with 12 traits that divide pretty cleanly along those three areas of responsibility: technical capability, leadership, and community.

For someone like me with fairly mediocre technical capability, this is reassuring.

Now if I only I weren’t also mediocre in those other areas too…

The Foundation of Technical Leadership · An A List Apart Article

Story of my life:

I have to confess I had no idea what a technical leader really does. I figured it out, eventually.

Seriously, this resonates a lot with what I find myself doing at Clearleft these days.

Weakend Productions : Jeb's Jobs

Hilarious tech support animation.