Category: Web Development

Posted on

Let’s do it again

Racoon-headed man in a yellow jumpsuit looks at a tablet while sitting on the beach.

Thirty years ago, the Mosaic Browser was released. At the time, I was deep in the BBS- and gopher-land as a teenager. But it was absolutely love at first sight of the web. I think it was my now brother-in-law who first showed it to me. I’m pretty sure I went to the website for the UofT engineering department, where he worked (studied?) – not exactly thrilling stuff. While memory should be treated as an unreliable narrator I can still remember the frisson of seeing it – that sense that everything had just changed forever. I don’t think I have felt similarly about anything – until I used ChatGPT for the first time a few months back.

What seemed immediately obvious to me looking at a website; looking at the source-code behind it was that we had just changed the nature of the game. We had just democratized access to information in an irrevocable way: publishing, advertising, research – all of these things were previously gate by costs, by expertise, by monolithic corporate and government entities. I probably didn’t have those exact words as a teenager, but I understood it, and most of my early professional work reflected this: I built websites for not-for-profits, for activists, for small startups. We all worked fast, we made mistakes fast, we changed things quickly. We put our interests online in the public, we helped our friends do this too. If we couldn’t match the slick professionalism of traditional media, we would simply run laps around them by pace of iteration; and we did. The web in some ways is a repeated case of of a small early influencer changing the course of giants – and endless set of peas-in-mattresses disrupting the bigger things around it.

And, of course, we lost our innocence. As the web matured, and spread it inevitably changed, and with money, it centralized and stagnated. There’s more websites, there’s more internet than ever and it somehow feels more homogenous than ever, dominated by a few players. Kind of like what the world felt like in the mid-90s. [cue: old-man-yells-at-cloud]

My first conversation with ChatGPT was similarly mundane: I asked it to create some dialogue for a villain in a D&D campaign scenario. But the outcome was similar – that deep sense that everything had just changed – again. The pace of iteration likewise feels similar (although it is clearly faster), and it leads me to my main theory here: We have just democratized access to development in an irrevocable way: learning, building, advertising, writing, research – all of these are currently gated by costs, by expertise, by monolithic corporate entities. At the beginning of 2023 starting a company has simultaneously never been easier and never been more out of reach for most: all of our economic models reward hyper-scale and hyper-centralization. We have a few monoliths lumbering around and proactively destroying competition by buying them and as often as not – shuttering them. This is why the internet feels so banal, homogeneous these days.

Concurrently with the arrival of game-changing technology, we’ve seen the cracks of the early-21st century economic model of Technocratic robber-barons leveraging cheap, plentiful capital to just buy moats with cash. Higher interest rates, repeated self-destruction by founders, the pandemic completely shaking up work models all present opportunity to rethink how we work, how we build.

So here’s my naïve, idealistic take: with generative AI tools, the cost to build has plummeted – you no longer personally need deep technical, design, content skills to create something. On top of that, current financial constraints mean that there’s actually a disincentive to scale first. In several current oligopolies we are seeing small players carve out niches in the shadows of lumbering giants – local rideshare & deliver services; fediverse social media; localized ghost-kitchen companies; niche search engines; etc. Our AI-agent tools are simultaneously revolutionary and shockingly basic. And this – likely temporary – state means while we can build small (simple) things blazingly fast right now, larger – more complex – things are harder and slower.

So let’s build things – tiny, single-serving, single-purpose things; niche products where generative AI have flattened the landscape. There’s a marketplace ready for the taking where your economics at small scale are better than those at large scale. If you’re at all entrepreneurial, or dissatisfied with how something works for you – try solving it! browsing the Midjourney community showcase reminds me so much of early GeoCities and LiveJournal – just an explosion of creativity.

The early web was full of bad ideas, failed experiments, small-scale and large-scale work all jostling together, and we need that again. We’ve got 30 years of internet diversity, privacy and security knowledge to make all this better, safer, more inclusive, but – it is OK to make mistakes and be wrong and small scale! Do it over and over again!

And for those thinking bigger: the early web in some ways was grown by monetizing various unix commands and turning them into mass-consumable actions; my hypothesis is that there’s a similar opportunity now via generative AI, but it is less about technical actions than it is about social action. Monte Cook’s Cypher System is a table-top system that introduces characters as “I am a [descriptor] [type] who [focus]” – Adjective, noun, verb – which is remarkably similar to AI-prompt. Apps that can do that for people, repeatably and predictably are going to supercharge huge amounts of labour:

  • I am a friendly writer who produces alt text.
  • I am a serious accountant who checks your math
  • I am a dedicated animator who recreates your idea in 3d.
  • I am a conscientious assistant who manages your inventory in Shopify

Put a few of those commands in a box to generate business-in-a-box tools; and the cost/effort to do things gets ever-lower for everyone.

Posted on

Post-Burnout, Self-Identity

I’m not sure if I’ve been particularly explicit, but around when we sold Pencilneck, I was really suffering from burnout. At the time, I fully intended to entirely abandon the tech industry – maybe go to grad school, maybe this, maybe that – I didn’t really know what would be next – but I was 100% sure it would not be more of what I was doing. I’ve tried a variety of ways to write about this – I saw today that I have some dozen drafts that are somewhat related to this idea, but I’ve decided to stream-of-thought this to just put it out there rather than frame it essay-style.

I took on some work post-sale – “doing what I knew best” which was writing code. But a thing that I’m not sure I’ve ever voiced publicly is some of the visceral effects of my burnout. Sure, I had a hard time concentrating, and very low productivity, but in particular, a lasting, lingering effect was massive anxiety, burgeoning on panic, every time I opened an IDE and tried to write code. I did some of this – but, unlike the previous 20-odd years of doing this work, this stopped being my happy place, indeed, became this place of doubt. The spiraling bad thoughts meant that my heart wasn’t in it. I was generally fine with implementing work, editing existing things – I helped wrangle some Drupal and WordPress here, a little Django there – but this was tying other people’s work together, not writing new modules, not original programmatic thought.

The work I did at the time that I enjoyed, indeed, that brought me back to happiness was shifting my thinking from systems thought to structural or organizational thought. While that had been an increasingly large part of my work up to then, it has driven almost all my work since – and I love this.

So while yeah, part of this is definitely professional growth, I still find it weird that I no longer enjoy writing code – I have self-identified as a programmer since.. probably since I first discovered Basic when I was 8 or 9 years old. And I don’t any more – and this has certainly cause no small amount of Imposter Syndrome feels – most often when talking to developers about their work, or their progress the how dare you pretend like this is strong. And all of this is related to that same basic panicky instinct when I think about writing code. Exploring that, pulling on that uncomfortable thread, getting comfortable with my discomfort has been helpful – I’ve learned that it’s not the writing code per se, but rather my experience of what comes next – other people’s excitement, expectations, the burgeoning responsibilities, the pace of work, the endless, relentless crush of running a business where I am the engine, vs the simple act of writing code, solving at the function level.

I started this post with maybe a different intent than I find myself now at – I wanted to say maybe how much better I feel. But the truth is that I’m not sure I do. I have ideas that I’d love to explore. And importantly, I no longer feel panicky at the thought of writing software. But I think more than anything, I think I’m slowly, in what feels like a healthy way vs an avoidance, coming to terms that I no longer think of myself as a programmer (engineer, developer, etc). And I’m not sure I know that means entirely, yet. I love technical architecture and problem solving and systems design and platform tooling and the commensurate things that go with what I do. I have recently dug in and started playing with Swift, which I’d never used before, and didn’t feel panicky at all thinking about the idea of writing something.

But maybe this is the crux: I’ve spent my whole (adult) life deeply embracing the idea that if I have an idea, not only could I built it, but that I should build it – only I could built it – and if someone else if working on it, I always need to be able to jump in and finish it. The shift from “Individual Contributor (IC)” to “Leader” happened for me ages ago – but a large contributor to my burnout was this persistent thought I had to be able to be the best IC in a pinch, no matter what. And I don’t know entirely what this means, but I think I’m increasingly comfortable with the idea that if I have an idea, I don’t have to be the one to build it? Ideas are nothing without execution – but execution can maybe look something more like general contracting, organizing others rather than individual craftsmanship? I directly support at team of about 30 right now (and indirectly influence a fair number more), and there’s no scenario where my time is not better spent enabling, unlocking, supporting, coaching, planning, reviewing etc for all and any of them vs me doing any of their work. And that’s ok? that’s good. It’s pretty great, actually. These awesome people are executing – sometimes on my ideas, more importantly mostly on theirs. I deeply love what I do these days – but I wish I had a “definition” for it as simple as “I’m a programmer”.

I’m not entirely sure what I am now.

But to circle back, and maybe end on a down note: burnout is real, and the effects are maybe permanent, and I wish that I had paid more attention in the moment to the shifting sands of what game me bad, panicky anxiety vs what was giving me good, excitement anxiety. A little therapy, a little coaching, a lot of introspection has really helped me. I still don’t enjoy programming like I used to and (most days), that’s ok.

Posted on

The Four Jedi (software architects) You Meet in Heaven

Millenium Falcon at Galaxy's Edge

*with apologies to Mitch Albom, of course. We recently got Disney+, and I finished watching The Mandalorian, and then, casting about for what else there is worthwhile, dove headlong into The Clone Wars animated series. It’s great! And somewhere deep in my subconscious, this analogy emerged.

After writing about the paths to Senior Developer, I’ve been thinking about what comes after that. Specifically about what comes after that at TELUS Digital, because that’s where I’m working. Important caveat here:
these are my musings, and not official TELUS Digital policy.
It should also be noted that the types of technical roles quickly bifurcate over and over like a career river-delta if you survey the industry: tech leads, team leads, staff engineer, fellows, principals, architects, managers, etc, so as you talk about more senior technical roles, there’s a higher-chance that you’re being very specific to your current organization. I asked on twitter about one facet of this too, as I thought about tech leads vs architects.

That I ask this question probably reveals a fair amount of how things work at TELUS Digital. But this also made me thing very specifically about the delta in those roles here, as I see it. I’ll talk about the tech lead role another time, but want to think about Software Architects, and the kinds of skills, focus and interests that make for good candidates.

Anakin Skywalker: The Solution Architect

Anakin Skywalker is confident, quick thinking – surging headlong into trouble and thinking creatively on his feet to find a solution to the problem in front of him. This is the kind of architect I’m the most comfortable speaking about because it is how I self-identified when doing this kind of work. It is a broad rather than deep role – a good solution architect can think creatively, laterally about a problem and propose a variety of potential outcomes to solve it. I’ve seen this role advertised many places as a web architect as well. If you’re a developer who loves the challenge of working in an unknown space, who prefers prototyping to refactoring or incremental improvements, this is a great fit. A solution architect has an obligation to keep current on shifting trends – be knowledgeable across a varied set of technologies, frameworks, languages, etc. More importantly than what you do know is a deep understanding of what you don’t know. A good solution architect will know to bring in other expert voices to stress-test and verify an idea. Because of this need, solution architects need to have pretty solid social skills as well to succeed, and should work more closely with developers on a day-to-day basis than others.

Of note: if you know the story of Star Wars, you’ll know that things do not end well for Anakin Skywalker, who falls to the dark side and becomes a force for evil. While this may be really stretching this metaphor, this is a useful thing for solution architects to think about too – too often we hear of Ivory Tower, or “architecture astronaut” if you don’t stay connected to the work happening.

Mace Windu: The Domain Architect

Mace Windu is a master of lightsaber combat, wise and careful of words, thinking deeply about the practice of his craft. He is a specialist, through and through. Domain Architecture is a path for deep specialization and knowledge. This is also variously called a practice lead. This is a good role to think long and deeply about a particular topic to develop unparalleled expertise in it. Spending time learning from, and talking to other experts in your domain is important in this role, to ensure that you do not end up so specialized in your particular company’s needs as to lose relevance. A key duty of this architect role is to impart knowledge to the people around you – both technical and non. More so than a solution architect, ensuring that there is a succession plan – that there is a clear apprentice to follow on is a good practice. Some examples of domains of specialization: Network Security, Testing, Telemetry, Performance, Data, etc. This role is still one of software, and so spending time writing, refining best-practice examples; pushing the state-of-the-art forwards are key outputs from a domain architect. Leading development of mission-critical implementations within your domain is also an important role for this kind of architect.

Obi-Wan Kenobi: The Integration Architect

Obi-Wan Kenobi always saw the underlying truth of a scenario as a way to find the way through it – never hurried, always already where others were going to. He understood, holistically, what was happening around him. This is a role for understanding what lays beneath: how different tools, architectures, endpoints, etc work together. It demands an incredible ability to keep hugely complicated systems in mind and be able to anticipate side-effects and unexpected outcomes from new additions. I’ve only encountered this type of architect at very large companies that have very complex, often legacy systems – a smaller scale operation is unlikely to require this kind of specialization. Interestingly, I’ve met several excellent integration architects who came into this from a business or system analyst role, as well as from a developer role. Integration architects, in my experience, make and maintain the best diagrams, are excellent teachers to others, and unparalleled in their ability to reduce complexity into more digestible chunks. If you’re a developer who likes working on edge-cases, who likes to find the weird exception to every rule, or who likes to think holistically about an entire system, this is an excellent role. It is very much a role of incremental operation of a whole system, rather than rapid prototyping or deep dives. It’s a great place to iterate on a particular system for a long time. If you want to have impact at scale through small incremental change, this is exactly that type of role.

Yoda: Principal Architect

Yoda guides the entire Jedi council with a clear vision of what a Jedi can be, should be, and helping everyone stay on the path to that vision. Including a Principal Architect may seem something of a cheat, in that I would consider this an additional tier of seniority than others – certainly at where I work now it is – but it isn’t always. Sometimes, it is the only architect. And this is largely a visionary role, to look forwards towards what might be, what can be, what must be for organizational success. It needs to be an architect who can think broadly about the range of opportunities to improve technology, who can work with other leadership to translate technological vision into business relevance. At some places, this role may well simply be the Chief Technology Officer (CTO). At somewhere large enough, there may be multiple principal architects, spread across the vast swathes of organizational complexity. A key duty of this role is to help support all the other architects as well – to provide support for their decisions, to provide rigour in decision-making, to ensure that everything roles up towards a coherent vision of good.

Do these kinds of role exist where you work? There’s probably all sorts of variants of this. For TELUS in particular, the software architect path is generally for people who want to stay primarily as individual contributors, rather than leads/managers. A path of bits, rather than heartbeats as it were. One thing I wish I had more insight is to what some key differences between something like a staff engineer and a software architect. Do places have both? My instinct is what I’m calling a solution architect may be akin to the staff engineer elsewhere, but YMMV.

Posted on

Developer Levels: evaluating professional growth

This is one of those things that my instinct with developer levels is “I know an [X] developer when I see one” – but if you’re a developer reporting to me, that’s completely useless. It smacks of subjectivity, of hidden gatekeeping. It would be really hard to argue with me if my position is simply “you’re not it, yet”. And because I currently work with some of the absolute smartest, most skilled developers I’ve ever had the pleasure to work with, I’ve needed to think long and hard about this. Because while they’re all great, they’re not all at the same level of title-seniority. This is also a topic that has been written about many times. I’m focusing here on roles we have at TELUS. For a great wider/larger look at titles, please read @reiver‘s post “Software Engineer Title Ladder“
At the same time, internally, we’ve been looking at building out a better career matrix in order to help guide these conversations across all disciplines. We’re still working on them – but with any luck, I’ll be able to share out at least our developer matrix (NB: in Canada, we don’t talk about engineers, but developers. If you’re elsewhere, you may substitute as per your comfort level). So with all those caveats, here’s some ideas I’m working through:

Problem Solving

  • A Junior Entry-Level Developer (I don’t particularly like that term junior – it feels vaguely pejorative – but that is another topic) is someone whom I can hand an identified, solved problem, and they are be able to implement the solution. I expect all asked-for particulars to be included, but I also expect questions to be asked, that the occasional thing might get missed, and that they would not necessarily be able to balance conflicting priorities in code without guidance.
  • An intermediate Developer is someone whom I can hand an identified problem, and they are be able to provide one or more solutions and implement it/them. They are be able to discuss the merits of each solution versus the identified problem’s parameters. I expect good testing habits, and a reasonable attempt to balance multiple concerns during implementation.
  • A Senior Developer is someone who can identify a problem that needs to be solved, include wider concerns when considering solutions and then guide implementation. They are able to help guide other developers when working through ideas, and help shape the work output that results. Senior developers can execute with a very strong understanding of the product lifecycle – so their work can have huge impact on the shape of the code base over all.

All of the above is not linear, and very open to interpretation. You’ll note I don’t talk about particular skills – in part because I’ve been looking for a through-line that would carry across different specialties, but also because my experience mostly tells me that skills and knowledge accumulate as you go. I’ve also several times encountered the inverse problem: deep specialization in one stack or skill leads to blind spots that I find troubling at more senior tiers of work. Either way, these conversations are hugely individualized and hard to generalize. But I think a useful way to put it might be: seniority is a combination of deep knowledge and broad application. Lateral thinking is important, as is deep knowledge and strong skills.

Mentorship

The other key ingredient in developer growth is on the mentorship side: Writing software is a team sport. Mentorship is multi-faceted, and can consist of a variety of things: lessons-learned, code practices, problem-solving skills, organizational-awareness, skills from other disciplines, leadership skills, etc, etc. This can be direct pairing, training opportunities, group work, special projects, etc. Mentorship is itself a program that can either reinforce existing biases or slowly shift them (that link is from 2008! sadly still feels relevant). So being incredibly intentional. both as an organization, and as a people-leader, about what is wanted out of a mentorship program is vital.
I believe that all levels can participate in this, in different ways:

  • An Entry-Level Developer will seek guidance, and share news ideas back into the community. If you’re learning, one of the best ways to learn is to do it publicly (see this very post. This is a lifelong thing). And asking questions demonstrates an important level of humility. And so junior developers looking to grow will proactively seek out opportunities to be mentored, or to surround themselves with senior developers. There’s… there’s a level of privilege associated with this idea that I’m still working through – just being comfortable asking for mentoring. The other side of this is the “new blood” idea: change is constant, and junior developers not set in their ways are amazing at surfacing new ideas, techniques and technologies otherwise dismissed by developers more used to “the way things are”.
  • An Intermediate Developer will share knowledge broadly and seek opportunities to mentor those following in their footsteps. This is the time in a career where confidence is high and more risk-taking has been earned. Be opinionated! But lean on data over opinions. And so writing, sharing internally, leading prototype builds, attending conferences. Because career mobility is very high, aligning resume development with org goals can be mutually beneficial. And in my experience, this is a time where personal ambition and organizational goals can be quite tricky to balance – investing in someone who will leave later is not the goal – but nor should it be deemed a failure. While knowledge at this tier is high, it is still being solidified, dedicated time and practice of mentoring more junior developers can help mature the intermediate developer.
  • A Senior Developer will lead patterns and practices, and stress the details with fellow developers. This may seem counter-intuitive – I’m largely saying intermediate-level should focus on board ideas, while senior developers focus on sweating the details. This is for a good reason: a senior developer will understand a level of nuance in problems that may escape a more junior developer. I often like to say that as a senior developer, the most important ability is to know what you don’t know. But you also may have wider organizational exposure, so leading initiatives in code review practices, testing patterns, performance techniques, etc will have huge impact. Lastly, if a senior developer is not actively mentoring one or more junior developers, they are not contributing enough – but the fault may not be theirs! One thing I’ve seen time and time again is that organizations get in the way of this practice – whether formalized or not – by demanding huge amounts of output from senior-level developers (arguing, perhaps, that they are paid a lot, so should write a lot), and not providing time to grow the rest of the team.

There’s obviously a huge amount that can be, that has been written, on this topic. And, because it is a complex relationship (and it might be another post?), I’m not including Software Architects (and all variants of them – principal or emeritus engineers, etc), who while generally more senior, represent a specialized career track in my opinion, as do engineering leaders (tech leads, managers etc). The question of “what happens next?” when you’re a senior developer is definitely one we struggle with a TELUS, and something I’m thinking a lot about.

One last note: willingness to be wrong is another axis I think is important, where both junior and senior developers are more willing to admit to being wrong than intermediates – and I think this curve is a good sign of growth.

Role Fit

This question comes up a lot in context of the above – what comes next when you’re a senior developer? But this actually a really important conversation to have at all levels. I’m a big believer in the Pioneer / Settler / Town Planner model of types of work (note: that particular phrasing gives me distinct qualms, due to the genocidal history of pioneers & settlers in North America. Bear with me, please), that I believe Simon Wardley coined (at least, his writing was my introduction to it).
People are not all the same, and are not excited by the same types of work. This may seem really obvious, but I have only twice, in 25 years of doing this, come in to a company that didn’t essentially consider all developers to be the same person in some basic way. Maybe distinguish between front- and back-end, or developer and QA roles. Very little is done, in my experience, to help developer self-interrogate as to which kind of work they like to do, and sell all kinds of work as being equally exciting and important (see: unconscious bias).

  • An Entry-Level Developer should be given opportunities to explore various roles: both in style-of-work models, but also in specializations. Early-specialization is as problematic as early-optimization.
  • An Intermediate Developer will develop a sense of their preferred model of work: indeed, this might be the key outcome of this portion of one’s career. Note that having a preferred mode doesn’t exclude others – but it can help inform all sorts of personal career decisions.
  • A Senior Developer will have an understanding of their preferred model of work. Senior developers have experience, knowledge and a level of self-awareness that informs this. Everyone understanding this can help prevent square-peg-round-hole syndrome.

Note: Preferred working models can definitely change, either via personal interest or organizational mandate. But if as a developer, you find yourself struggling to fit in on a new team, reflect on this particular axis of work-modelling. Same for leaders, who’re not seeing the results they were expecting of a newly joined team-member.

Experience/time-in-role

I innately reject time-based markers of seniority for engineers, but nor do I want to completely discount them. But time-spent is not spent equally. An organization firing on all cylinders will grow senior developers much faster than one that is in disarray. I’ve also seen developers who’ve got 15-20 years experience who simply have not kept up with changing practices.

So… how do you tell what “level” a developer is? it’s not here yet, but I think but I think there’s a series of variables above that can help define that, but also an individual could easily advance very differently in each category, making these titles feel increasingly inelegant and arbitrary. Mapping these to defined organizational role-titles remains important though, because that how I can talk to my current team, and it directly affects compensation for them.

Reflecting on my own experience, senior developer is still, in the arc of possibility, not even the midpoint of a developer’s potential career progression. And that next transition point remains deeply interesting to me to think about.

Posted on

Managing through aphorisms

They’re clichés, sure, but are for a reason. And in a sound-byte driven world, having a punchy phrase to summarize what is often full of nuance is useful. I find myself returning to these as mantras, rallying cries and whatnot repeatedly as I lead a team, pull in collaborators and stakeholders, and generally try to make better software in better ways.

Default To Open

In what is probably the most surprising 180 from my early career, I lean deeply on this idea, across several ways:

  • open source your code. This has a few effects: write all your code like someone else is going to read it, that you don’t know. Make sure your code is functional. More basically, thinking in an open-source mind changes some approaches.
  • Talk about your work openly. Learn in the open. Share your learning, your success, your failures. Write about it. talking about. Let anyone who wants to follow along follow along. This helps remove some barriers to being vulnerable in my experience, and can help sharpen thinking by actively, consistently reflecting on work in progress.
  • Give access to your work. Open your backlog for others to see. Keep tickets available to submitters so there’s no back-channel. Talk in open channels not private messages. All of this can help drive a practice of asking questions, being respectful of others’ learning, a safe space for vulnerability, and being kind to clients/stakeholders.

Aim for Less Wrong

At all times, assume you’re wrong. Your goal is to get to be less wrong. You can only validate how wrong you are by talking/sharing with others, and being humble about that. And understand that everyone is wrong at the start, and constantly working to get to less wrong. I’ve found that by repeating this over and over, it can help lead to some changes:

  • asking more questions
  • being kinder in response to “dumb” questions
  • putting something into existence to work on/against, vs being paralyzed by choice to start. It’s easier to talk about something in particular vs a general idea “let’s do X” rather than “we should do something” gives an opportunity to change X.
  • It removes the stigma and potential shame about being wrong – you’re already wrong. Know this, accept this, and aim to be less wrong.

Writing software is a team sport

This is sort of the corollary of go alone to go fast, go together to go further. You need others to be successful, because everyone is full of biases, and other people help you get around them. And people with different skills are required for a good team. I’ve found this is a helpful gentle nudge away from individuals who constantly want to be a hero and take everything on by themselves too.

Write less software

Perhaps ironic for a software team, but the best software is the software you don’t write. Much like how a car loses half its value as you drive it off the lot, All production software is legacy someone needs to deal with in the future. So write less of it. If you can use someone else’s software? if your default position is “I don’t need to write this”, it can really give focus to the decision that, indeed, you do need to write it. Can you justify why you haven’t just used someone else’s software? it is worth the effort, the cost of maintenance?

Write boring software

This goes along with the above. We all want to write super-brilliant, complex software that’s on the cutting edge of everything because we’re that awesome. But guess what. Chances are that you’re only going to be responsible for 10% of that software’s life. OTHER people – OTHER systems will have to be able to work with in in the future. So if you follow common patterns, you lower the cognitive overhead to learn it. and maintain it. Resumé-driven Development should be avoided in almost all instances, because software needs to live in teams, not individual’s heads. It also means to, more often than not, move cautiously. Don’t adopt that rad new framework just because it is there. The larger the organization, the more important this is. Human ability to share immense code-bases because of predictable patterns is major advantage.

Progress is more important than excellence

Everyone wants to be the best. Strive for that. But perfectionism is the enemy of good (is that another aphorism to live by?). What’s important is consistent progress towards better on all plans. experiment, iterate, improve. Fail one time? that’s fine. learn and do it better next time. If you’re the best, if everything is excellent, you’re in the wrong job – because you’re not being challenged. Similarly, if you can no longer progress, you’re in the wrong job – because you either don’t care or you’re in the wrong role for your skills.

There’s of course and endless list of these. These few keep cropping in conversations over the past year or so. Other things I’m trying to find good wording for is around the concept of how good software is living, or like a plant, or something – that you have to maintain it, update it, let it adapt to the world around it, etc.

Posted on

Professional Update: July 2018

set of old mobile phones, from largest to smallest

Since selling Pencilneck Software two years ago, I’ve very much enjoyed my time since then, spending more time with the kids, and running Codegnostic, my fractional-CTO consulting company. I’ll forever relish the opportunity of these past two years to be more involved with school and kid activities on the personal side, and the work on organizational change, growth and process improvement on the professional side. But nothing stays the same, and this is true for me too.

I’m extremely excited to announce that I’m joining TELUS Digital in the role of Senior Technology Architect, starting tomorrow, July 3rd. This role looks to be a really exciting & challenging extension/deep-dive on the work I’ve spent much of this decade doing on the technical management side, and I’m really looking forward to the opportunity to do this at a large and rapidly-growing organization.

Posted on

Quick Thoughts on the new MacBook Pro (with touchbar)

After 5 years of service, my trusty, much-loved iMac died suddenly (and of course, in the middle of trying to meet a crazy deadline). We also had a 5-year old MacBook Pro in the house – the family computer, and my backup computer.

Because I work from home (which means I work from coffee shops, and other people’s offices, it made sense to replace the iMac with a laptop). After briefly flirting with the idea of a) switching to windows and b) getting a refurbished older MacBook, I took the plunge and ordered the brand-spanking new MacBook Pro 15″ with Touchbar (I need a shorthand for that. TouchBook? MBPT? Ehhh). This new system, like all first-generation Apple products, has not been without its issues.

Following personal priorities, I ordered a version with the 2.9 GHz quad-core i7 CPU, Radeon Pro 460 with 4GB, and the standard 500GB HDD (my rules: always max-out CPU/GPU capabilities on a laptop, deal with everything else). I’ve had the system for about 8 hours, so these are all early impressions:

The Good

  • The screen! Oh, the screen. It is so, so lovely. I’m somewhat colourblind, so I wasn’t sure I’d be able to see the new color range, but I can absolutely, 100% see the difference, particularly when looking at my photos. It’s one of those “it’s hard to describe but you’ll know it when you see it” differences.
  • The keyboard. My favourite-ever OS-X era Mac keyboard. So clicky! It feels much like an old-school mechanical keyboard, despite very clearly being not at all.
  • Can run ALL THE THINGS. I usually am working with several VMs. On the old iMac, I would regularly run out of RAM, so I’d habitually spin up a VM, work, shut it down when done and move to the next project, spin it up, etc. Doubling the RAM has made that unnecessary – I’ve currently got 4 VMs up and running for my current projects. With all those running, I could still play Civ VI without the system breaking a sweat.
  • Games: I don’t do a lot of graphics work, apart from photo-editing and the occasional video. But! I do play games. I played both Civ VI and Cities: Skylines last night, and was able to play *both* in “High Performance” mode, for the first time ever on a mac. It was so lovely!
  • Touchbar: TouchID makes virtually every issue ok. Interestingly, it would appear that the “needs admin password” is not some sort of “core” system, because, while anytime an Apple app asks for it, I can use TouchID, I couldn’t, for instance, use TouchID to give Adobe permission to install Lightroom. As apps update, touchID will just become better and better. But 1Password + TouchID is everything. I’ve just started customizing the touchbar, and I think that as I do that, I’ll come to like it more and more.

The Bad

  • Touchpad: It’s too. damn. big. It feels weird. I keep getting issues from my palms touching it while I type. Because it is so big, I have to retrain some gestures that expect me to use the whole space: 4-finger pinch, swipe from edge, etc. I’m also not a fan of how it “clicks” – this is similar to my issues with the new home button on the iPhone 7 – they both are in the “uncanny valley” of clicking for me, that somehow makes them feel cheap and plastic, not nice and solid.
  • Touchbar: I know, I know, I liked it. But – I keep accidentally tapping it with my fingers and having weird things happen – in particular the escape button. Also, I sure wish that the touchbar provided haptic feedback so it felt like I was clicking on something, rather than brushing against it.
  • RAM: I know I just said above that it could do all the things. But given that 16GB is the “currently comfortable amount” of RAM I need to do my work, I worry greatly that this will artificially limit the lifespan of the computer to 2-3 years, instead of the 5-6 I’m hoping for.
  • Buggy: I’ve already had to restart the computer twice because of weird issues: The first time, all of a sudden the system was no longer recording clicks within app windows. Anything outside worked, but not within. The second time the keyboard just stopped working. couldn’t type anything. Super weird. All things that can be fixed via OS Updates, but annoying. I’m used to not restarting my macs for months on end, not every day.
Posted on

Making Money isn’t Enough: Considerations for a digital company in 2017

I’m starting a new company, with Steve Fisher. I can’t reveal just yet the first product we’re building, but don’t worry, there’ll be more on that in the not-so-distant future. This post is focused on deeper considerations about the company we’re building and why those matter.

In 2015, at The Design & Content Conference, I watched Sara Wachter-Boettcher give a career-altering talk on designing for kindness.

In 2016, this theme was built upon at the same conference by virtually every speaker, but I want to call out two in particular who’ve stuck with me:

Anil Dash’s talk “Storytellers” — particularly the unintended consequences of design decisions, and accountability at a personal and organizational level for them. The Alexa Story, starting at 3:45 is such an excellent illustration.

Ron Bronson’s talk “Designing for Empathy: Context Matters”, largely about the idea of recognizing one’s own blinders and working through them to discover other context, other uses. The story about Pokemon Go/Ingress starting at 6:35 is solid example.

These three talks in particular have informed a pretty massive shift in my approaches to: code, operations, design, business, etc. Positive shifts that also come with a set of concerns that I hadn’t been as focused on.

Concerns we will address:

Geophysical Portability

We’re going to have customers, at least to start, across North America. I also recognize that where your data resides has become more important than ever. For many companies and organizations, where their data is stored, and the locations of libraries they use matters. In BC (Canada!), government entities aren’t allowed to use US-soil services. Governments will use our product, and so we need to ensure that every piece of code we run, every piece of data we store resides in their country. So, from the get-go, we need to write software that is portable and works with third-party-hosted libraries, tools or services that are similarly portable. It’s an interesting and exciting constraint.

Our Privilege

We’re two middle-aged, middle-class white dudes from Canada starting a tech company that is mostly self-funded. The privilege in that is staggering. Basically, we’re walking around with blinders on when we think about the product, the company. We need to do the work to see past our own biases and blinders. First step for us is to engage with a set of advisors who are significantly more diverse than we are, to provide alternative insights and voices in our planning. AND, most importantly, pay these advisors fairly for their time.

Protecting the Vulnerable

The product we’re building exists to help our customers. But it only took a few minutes to think of how someone could abuse our product to help them advance their less-wholesome objectives. Unintentionally so, but it would be easy to use this tool for bad. It is our responsibility to build in constraints, restrictions, community, etc that could prevent this. But, how far does that go? Not everyone is going to do things I like or agree with — but they’re not necessarily bad. Nothing is politically neutral, but do we want to have “neutral” software, run by an opinionated company? We’ve seen first hand the damage that can cause with companies like Twitter. We need to dig in and discover what tools, features, guidelines, legalese we can, and should, build into the product and company. It should be part of our job to build tech that protects the most vulnerable.

Data Security

We will be tracking lots of activity within our product. This is for growth targets, sales, insights and customer support. All good reasons. And we will require user accounts. For most use-cases that’s not an issue, but I can’t guarantee that’s true for everyone who might see a use of our product.

Some guidelines we’re working from:

  1. Data security must be baked-in at every level.
  2. We hold our customers’ data in trust, and data should only be used for our collective greater good
  3. Our customers’ data remain theirs, and they should be able to remove it as needed.
  4. Data available online is vulnerable. It is our duty to both minimize that vulnerability and to act responsibility if it is ever targeted.
  5. Privacy doesn’t mean the same thing to everyone. We must support various levels.

Tools & Software

We’re building the first version of this software on our own, but hope to be able to hire engineering staff quickly. Cutting edge is less important than broadly known — for both hireability and learnability. Our team will leverage, and contribute back to, existing and potentially new open source projects. Where possible, we will prefer open-source tools over proprietary (particularly given our concerns about geophysical location). We’re building a web-app first, but I expect we’ll soon see use for both a mobile-native app for at least parts, and, perhaps less expectedly, a desktop app.

HR

We need things such as revenue, first, but I’ve learned from my previous companies that hiring happens faster than you’d expect, and having values and policy in place is essential.

Some things we’re thinking about:

  1. Both Steve and I have dogs, who we want to have around the office.
  2. We have kids, and we like to see and hang out with them.
  3. We like to travel.
  4. Be able to offer valuable perks like full parental leave, childcare and flexible hours.
  5. Encourage and support community involvement and personal passions.
  6. Collaboration and conversation is better than competition and direction.

But, I don’t want an office full of perks and free things. There’s some middle ground of “recognize your staff have lives and accommodate fully” and “your staff should be treated like adults” Be passionate, stay passionate, engage and encourage passion, but leave work at work. A few years ago, I wrote a piece about finding other paths to success (“A million dollars isn’t cool, you know what’s cool?”), and the ethos behind that still resonates with me. I want to build that into this new company.

Utility

I’m confident we’ve identified a need and a niche that we can work in, but there’s something to the axiom “the greatest minds of my generation are figuring out how to make people click ads”. There are real problems that people can, and are solving. Teams at Code for America & the USDS are solving real problems, for real people, using tech. We need to make sure we’re contributing too — if not directly through our product, through our expertise, our staff, our community.

A Company for Good

Starting a company is hard. Most fail quickly, so adding additional constraints, or targets could feel like a fool’s game. I’d like a company that structurally contributes back to our community (see HR, above). And I’d like a company that isn’t just building a product and selling it. Existing isn’t enough. We need to put our effort, success, and privilege towards something more. We’re not totally sure where we’ll draw the line, but it’s something to figure out. It’s too easy to leave these decisions to later, and then later never comes. We need to start these as we start everything else.

These are not in order of importance and jostle from day-to-day in my head for position. As we move forward I will to write more about how we embrace these challenges and opportunities How each point becomes not only part of the product, but of our new company, and more part of ourselves as partners in this. And finally to talk openly about where compromises were made, where things are left to do, and how we’re changing.

“All we have to do is go to first principles and what you all know every single time you ship something, every single time you put something out in the world. You know what it looks like when it counts. You know what it looks like when you care about it, and all we have to prioritize, one simple thing, that the story we tell includes the most vulnerable people. If we do that much then we can be worthy of all the things that people say about the transformative potential that technology has on the world.”
Anil Dash at The Design & Content Conference

Posted on

MacOS Sierra: Solving an external drive mounted as read-only after install

When I installed MacOS Sierra, my trusty Drobo, who’d been flawless through so many OS updates, suddenly stopped working. Or, more particularly, suddenly was no longer writable. I just solved this, and, as I was unable to find any of this online, thought I’d write it up in case anyone else has this issue. Particularly as Drobo’s support suggested:

If you’re like me, you have no media capable of holding everything in your Drobo.

Of note: My Drobo is formatted HFS+. If you’ve got an external NTFS or FAT drive, YMMV.

The cause of this change is that in MacOS Sierra, the /Volumes folder is no longer writable by default. So, to change, I needed to do the following:

First remount the drive as writable:

sudo mount -u -w /Volumes/YourDriveName

(the -u means you’re modifying an already-mounted filesystem; -w makes it writeable).

I could now write to it if I sudo vi a text file. But — neither TimeMachine nor (most importantly for me) Lightroom could write to it at this point. It turns out that ownership of everything in the Volumes folder changed too, away from root:wheel. So, next step:

sudo chown -R root:wheel /Volumes/YourDriveName

(the -R is recursive, so all files. root:wheel is the owner & group — you could make this your own user, but I chose to make it match other “system” files here.

Lastly, check the read/write privileges. For me, everything in the Drobo was now -r--r--r-- (read only). Which just won’t do at all. I wanted everyone to read, and owner and group to be able to write. So, next:

sudo chmod -R 774

This changes permission so that the owner & the group can read, write, execute, and everyone else can read — which is what I wanted for this drive (in particular, group-writable was important for Lightroom, while TimeMachine seemed perfectly happy to start working with only the owner having write permissions).

So — this may have been a particular-to-me issue, but given that I have many, many TB of personal photos, videos — and TimeMachine backups on my Drobo, I’m certainly glad I took the time to solve this.

What’s left to do

So, I can read and write to my drive — but I still can’t figure out how to get the drive to show up in the list of Devices in the finder. I can live with this, but it would be nicer if it just “appeared”. If you know how to solve that (and no, clicking the “show external drive” off and on in preferences doesn’t work), let me know!

Posted on

Better time-leverage

I’ve started using Calendly to help manage my calendar & appointments. Right now, I’m using it bare-bones at the moment, to see if it works for me, because of a singular problem with all of these calendaring-automation tools that I haven’t figured out yet:

It feels dangerously self-important to ask people to schedule their own appointments with me.

I’ve always prided myself on my “human connection” skills within the tech industry, and the UI for all of the various calendaring apps still, in my opinion, feel like bots, not like assistants. Additionally, many feel like they want me to run my calendar in their UI, not work alongside my existing workflow.

Anyway — that’s just really an aside about the point of this post. Being a one-man-shop freelancer/consultant, time management is super-important. I’m also hyper-aware of how easy it is for a single meeting to run roughshod over an entire day’s worth of tasks, depending on its cognitive or emotional load. And so, when I book a meeting, I often then look to be most efficient by having other, adjacent meetings — a day of meetings feels productive. A day with a meeting, then an hour of heads-down time, then another meeting often feels like it was totally wasted.

Calendly, which offers a “buffer” around meetings, which is great — but doesn’t appear to offer any location data — which is important to me because I often (and indeed, usually prefer) in-person meetings. Which involves travel. So, if when booking an appointment, Calendly could ask for a where, then use my office location to calculate travel times, add that to *my* calendar time and buffer around that meeting, it would become vastly more useful.

But once I’m in a location, it would be great if I could schedule other meetings nearby:

  • On a hyper-local level, if I’m having a coffee meeting in Gastown, it would awesome if Calendly connected to my CRM of choice, and see which contacts are near my scheduled meeting (ie, also in Gastown), that I haven’t seen in a while, and send me a note letting me know it might be a good idea to try to connect with them.
  • On a regional/travel level, if I’ve got an upcoming calendar trip to, say, Toronto, check my CRM to see who might be available while I’m there to meet with, and suggest it to me. (next level: find people I don’t know, but suggest I should try to meet them)
  • aside: this is a problem with calendaring I don’t have a good answer for: When I’m away, I generally mark that time in my calendar as “busy”, because I don’t want anyone here to book time with me. but, I might totally want to book time with people there. I want a “busy-in-location” marker, or a “location change” marker to connote travel vs just being busy.

I recognize there’s a lot of data mining/analysis going on there. And, most likely, that’s a service that shouldn’t be provided by Calendly, but rather integrate via API (although, I do think not supporting location/travel time is a big problem for Calendly at the moment). And possibly there’s already services that sit between these data-stores to do just this task that I’m unaware of. And that’s also, personally, an area of interest — software tools that work with existing data-stores for people to help tie them together in interesting ways, and surface helpful things for you, so I think a lot about pulling data out of silos and tying it together.

%d bloggers like this: