Justin Donato

• notebook
• projects
• about

• Summer 2023

  

  ▶

  
  

  

  2023-09-26

• A Model for Software Engineering Impact

  I have a simple model for thinking about software engineer impact:

  Competency x Effort x Problem = Impact

  The idea here is if you are good and you work hard on the right problem you'll have impact.

  Competency is your skill level. This can mean code writing skill, communication skills, leadership skills, whatever.

  Effort is just how much work you put in.

  Problem is what you're working on. Very roughly, the problem you're trying to solve. This might be building a new service, or mentoring more junior engineers. You might also call this "the object" of your work. It's the thing you apply your effort to and in reality its probably a bunch of things.

  This model is simple almost to the point of obviousness. And it seems right. But is it useful? I'll ask some questions.

  Which of the elements do you have control over?

  Do you control your own competency? Not today. You had control over the competency you have today six months ago or last year or when you were in college. And you can partially control what it might be in the future, but today you are sort of just stuck with how good you are.

  Do you control your own problem? This one is the most interesting. As someone just getting started you might have very little control over the problem. You show up to planning, you get assigned some tickets and that's it. As you grow in your career you probably have more and more control over the problem, at least within the bounds of whatever business you're working for. If you get senior enough, you might even have complete control and be expect to define your own problems.

  So for problem, I would say you share control over it with your manager and other leaders, but over time you take more and more ownership over it.

  Do you control your own effort? I would say yes. This one is pretty clear. It may be out of your control at times, for instance when you're sick or there is some life event taking a lot of your time and energy away, but for the most part I think we can say you pretty much control this.

  So there are three elements that decide impact and you get to control maybe 1.5 of them for most of your career. That's worth thinking about.

  What is the relationship between the elements?

  And are they all really weighted equally? If I increase my competency by 2 times, can I put in half as much effort? I don't know. And I've cheated by leaving out any type of units, but I think seems roughly right.

  It also seems to me that Competency and Problems are tightly linked by Effort. If you get good problems today and you put in effort, its likely that your competency will increase. Likewise you are limited in what problems you can take on today by your competency. I think this maps to the common goal of management at software companies as being directed at growing the size of the problem someone can take on.

  Knowing if the problem your working on is important is probably one of the biggest competencies you need. Which makes me wonder...what if I turn the model in on itself? You can make your problem improving your competencies. Or even finding a better problem. This is an interesting case because if you do this, you might not have a lot of impact on your business in the short term. But if I allow for the long term, I think the model holds true.

  How do I use this as an IC? Can I use this as a manager?

  I think the most useful part of this model is debugging when something is not working. Suppose you're working really hard, but when it comes time to talk about what you've accomplished, there's not just any impact. Well, either you're bad at your job or you're working on the wrong thing. It's probably that latter.

  For a manager, I don't think this model is suitable for making the case that a report had impact. But I do think this model can help as a means of reflection and to evaluate both your report's work and your own. For example, if you find yourself with an engineer who is having no impact, you can ask, which element does she need to work on? Or if you have an engineer you know is competent and puts in a lot of effort, you might come to the conclusion that you need to be guiding her to better problems.

  ---

  I find this simple model very helpful and I'll continue to use it. I'd love to hear your thoughts.

  2023-09-26

• Spring 2023

  

  ▶

  

  

  2023-07-09

• Creating a Vim Quickfix List Programmatically

  A Quickfix list in vim is a special buffer that stores a list of file and line locations. Using this list and some commands, you can quickly move through a list of edits.

  Normally, a quickfix list is created when you run the grep command, but there are lots of applications where you want may want a list of files and locations. For instance, imagine you create a list of places in your source code that you want to look into later. I have a vim plugin that pulls Github PRs comments into a quickfix list, so I can review comments in my editor and make updates right where I need to.

  The key to creating and opening a quickfix list programmatically is the cexpr command. cexpr takes a newline delimited string in a certain format. The format is defined by errorformat. You can set your own errorformat using:

  1	:set efm=<your error format>

  using special format % items. Here's a partial list of them:

  1 2 3

  %f file name (finds a string) %l line number (finds a number) %m error message (finds a string)

  See :help errorformat for the full docs.

  Note that errorformat can hold multiple patterns, delimted by commas, so before you set yours, check what you already have on it with :set efm?.

  Putting this altogether, lets say you create a file (quickfix.txt) of places you want to inspect like this:

  1 2 3

  file-a.py:14:this looks interesting file-b.py:26:I have to remember to update this file-c.py:84:This can be deleted when I am done

  And you have set your errorformat like this:

  1	:set efm=%f:%l:%m

  Then you can open that into a quickfix list like this:

  1	:cexp(readfile('quickfix.txt'))

  2023-05-13

• Winter 2022/3

  

  

  

  

  2023-04-01

see all