410 stories

What's a senior engineer's job?


There’s this great post by John Allspaw called “On being a senior engineer”. I originally read it 4ish years ago when I started my current job and it really influenced how I thought about the direction I wanted to go in.

Rereading it 4 years later, one thing that’s really interesting to me about that blog post is that it’s explaining that empathy / helping your team succeed is an important part of being a senior engineer. Which of course is true!

But from where I stand today, most (all?) of the senior engineers I know take on a significant amount of helping-other-people work in addition to their individual programming work. The challenge I see me/my coworkers struggling with today isn’t so much “what?? I have to TALK TO PEOPLE?? UNBELIEVABLE.” and more “wait, how do I balance all of this leadership work with my individual contributions / programming work in a way that’s sustainable for me? How much of what kind of work should I be doing?“. So instead of talking about the attributes that a senior engineer has from Allspaw’s post (which I totally agree with), instead I want to talk here about the work that a senior engineer does.

what this post is describing

“what a senior engineer does” is a huge topic and this is a small post. things to keep in mind when reading:

  • this is just one possible description of what a “senior engineer” could do. There are a lot of ways to work and this isn’t intended to be definitive.
  • I have basically only worked at one company and this is just about my experiences so my perspective is obviously pretty limited
  • There are obviously a lot of levels of “senior engineer” out there. This is aimed somewhere around P3/P4 in the Mozilla ladder (senior engineer / staff engineer), maybe a bit more on the “staff” side.

What’s part of the job

These are things that I view as being mostly a senior engineer’s job and less a manager’s job. (though managers definitely do some of this too, especially creating new projects / relating projects to business priorities)

The thing that holds all this together is that almost all of this work is fundamentally technical: helping someone get unstuck on a tricky project is obviously a human interaction, but the issues we’ll be working on together will generally be computer issues! (“maybe if we simplify this design we can be done with this way sooner!“)

  • Write code. (obviously)
  • Do code reviews. (obviously)
  • Write and review design docs. As with other review tasks, I think of “review design docs” as “get a second set of eyes on it, which will probably help improve the design”.
  • Help team members when they’re stuck. Sometimes folks get stuck on a project, and it’s important to work to support them! I think of this less as “parachute from the sky and deliver your magical knowledge to people” and more as “work together to understand the problem they’re trying to solve and see if 2 brains are better than 1” :). This also means working with someone to solve the problem instead of solving the problem for them.
  • Hold folks to a high quality standard. “Quality” will mean different things for different folks (for my team it means reliability/security/usability). Usually when someone makes a decision that seems off to me, it’s either because I know something that they don’t or they know something I don’t! So instead of telling someone “hey you did this wrong you should do X instead”, I try to just give them some extra information that they didn’t have and often that sorts it out. And pretty often it turns out that I was missing something and actually their decision was totally reasonable! In the past I’ve very occasionally seen senior engineers try to enforce quality standards by repeating their opinions more and more loudly because they think their opinions are Right and I haven’t personally found that helpful.
  • Create new projects. A software engineering team isn’t a zero-sum place! The best engineers I know don’t hoard the most interesting work for themselves, they create new interesting/important work and create space for folks to do that work. For example, someone on my team spearheaded a rewrite of our deployment system which was super successful and now there’s a whole team working on new features that are way easier to build post-rewrite!
  • Plan your projects’ work. This is about writing down / communicating the roadmap for projects you’re working on and making sure that folks understand the plan.
  • Proactively communicate project risks. It’s really important to recognize when something you’re working on isn’t going well, communicate it to other engineers/managers, and figure out what to do.
  • Communicate successes!
  • Do side projects that benefit the team/company. I see a lot of senior engineers occasionally doing small high leverage projects (like building dev tooling / helping set policies) that end up helping a LOT of people get their work done a lot better.
  • Be aware of how projects relate to business priorities.
  • Decide when to stop doing a project. Figuring out when to stop / not start work on something is surprisingly hard :)

I put “write code” first because I find it surprisingly easy to accidentally let that take a back seat :)

One thing I left out is “make estimates”. Making estimates is something I’m still not very good at and that I don’t think I see very much of (?), but I think it could be worth spending more time on some day.

This list feels like a lot and like if you tried to do all those things all the time it would consume all available brain space. I think in general it probably makes sense to carve out a subset and decide “right now I’m going to focus on X Y Z, I think my brain will explode if I try to do A B C as well”.

What’s not part of the job

This section is a bit tricky. I’m not saying that these aren’t a senior engineer’s job in the sense of “I won’t help create a good work environment on my team, how dare you suggest that’s part of my job!!“. Most senior engineers I know have spent a huge amount of time thinking about these issues and work on them quite a bit.

The reason I think it’s useful to create a boundary here is that everyone I work with has a really strong sense of ownership/responsibility to the team / company (“does it need to be done? well, sure, I can do that!!“) and I think it’s easy for that willingness to do whatever needs to happen to turn into folks getting overwhelmed/overworked/unable to make the kinds of technical contributions that are actually their core job. So if you can create some boundaries around your role it’s easier to decide what sorts of work to ask for help with when things are hectic. The actual boundary you draw course depends on you / your team :)

Most of these are a manager’s job. Caveats: managers do a lot more than the things listed here (for instance “create new projects”), and at some companies some of these things might actually be the job of a senior engineer (eg sprint management).

  • Make sure every team member’s work is recognized
  • Make sure work is allocated in a fair way
  • Make sure folks are working well together
  • Build team cohesion
  • Have 1:1s with everyone on the team
  • Train new managers / help them understand what’s expected of them (though I think senior ICs often actually do end up picking some of this up?)
  • Do project management for projects you’re not working on (where I work, that’s the job of whatever engineer is leading that project)
  • Be a product manager
  • Do sprint management / organize everyone’s work into milestones / run weekly team meetings

Explicitly setting boundaries is useful

I ran into an interesting situation recently where I was talking to a manager about which things were and weren’t part of my job as an engineer, and we realized that we had very different expectations! We talked about it and I think it’s sorted out now, but it made me realize that it’s very important to agree about what the expectations are :)

When I started out as an engineer, my job was pretty straightforward – I wrote code, tried to come up with projects that made sense, and that was fine. My manager always had a clear sense of what my job was and it wasn’t too complicated. Now that’s less true! So now I view it as being more my responsibility to define a job that:

  • I can do / is sustainable for me
  • I want to do / that’s overall enjoyable & in line with my personal goals
  • is valuable to the team/organization

And the exact shape of that job will be different for different people (not everyone has the same interests & strengths, for example I am actually not amazing at code review yet!), which I think makes it even more important to negotiate it / do expectation setting.

Don’t agree to a job you can’t do / don’t want

I think pushing back if I’m asked to do work that I can’t do or that I think will make me unhappy long term is important! I find it kind of tempting to agree to take on a lot of work that I know I don’t really enjoy (“oh, it’s good for the team!”, “well someone needs to do it!“). But, while I obviously sometimes take on tasks just because they need to be done, I think it’s actually really important for team health for folks to be overall doing jobs that are sustainable for them and that they overall enjoy.

So I’ll take on small tasks that just need to get done, but I think it’s important for me not to say “oh sure, I’ll spend a large fraction of my time doing this thing that I’m bad at and that I dislike, no problem” :). And if “someone” needs to do it, maybe that just means we need to hire/train someone new to fill the gap :)

I still have a lot to learn!

While I feel like I’m starting to understand what this “senior engineer” thing is all about (7 years into my career so far), I still feel like I have a LOT to learn about it and I’d be interested to hear how other people define the boundaries of their job!

Read the whole story
14 days ago
Share this story

What Is This Book?

1 Share

A beautiful paragraph, found in the introduction of every Bible produced by the remarkable Gideon International:

The Bible contains the mind of God, the state of man, the way of salvation, the doom of sinners, and the happiness of believers.

Its doctrines are holy, its precepts are binding, its histories are true, and its decisions are immutable.

Read it to be wise, believe it to be safe, and practice it to be holy.

It contains light to direct you, food to support you, and comfort to cheer you.

It is the traveler’s map, the pilgrim’s staff, the pilot’s compass, the soldier’s sword and the Christian’s charter.

Here too, Heaven is opened and the gates of Hell disclosed.

Christ is its grand subject, our good its design, and the glory of God its end.

It should fill the memory, rule the heart, and guide the feet.

Read it slowly, frequently, and prayerfully.

It is a mine of wealth, a paradise of glory, and a river of pleasure.

It is given you in life, will be opened at the judgment, and be remembered forever.

It involves the highest responsibility, rewards the greatest labor, and will condemn all who trifle with its sacred contents.

HT: Dane Ortlund

Read the whole story
28 days ago
Share this story

Security in a World of Physically Capable Computers


It's no secret that computers are insecure. Stories like the recent Facebook hack, the Equifax hack and the hacking of government agencies are remarkable for how unremarkable they really are. They might make headlines for a few days, but they're just the newsworthy tip of a very large iceberg.

The risks are about to get worse, because computers are being embedded into physical devices and will affect lives, not just our data. Security is not a problem the market will solve. The government needs to step in and regulate this increasingly dangerous space.

The primary reason computers are insecure is that most buyers aren't willing to pay -- in money, features, or time to market -- for security to be built into the products and services they want. As a result, we are stuck with hackable internet protocols, computers that are riddled with vulnerabilities and networks that are easily penetrated.

We have accepted this tenuous situation because, for a very long time, computer security has mostly been about data. Banking data stored by financial institutions might be important, but nobody dies when it's stolen. Facebook account data might be important, but again, nobody dies when it's stolen. Regardless of how bad these hacks are, it has historically been cheaper to accept the results than to fix the problems. But the nature of how we use computers is changing, and that comes with greater security risks.

Many of today's new computers are not just screens that we stare at, but objects in our world with which we interact. A refrigerator is now a computer that keeps things cold; a car is now a computer with four wheels and an engine. These computers sense us and our environment, and they affect us and our environment. They talk to each other over networks, they are autonomous, and they have physical agency. They drive our cars, pilot our planes, and run our power plants. They control traffic, administer drugs into our bodies, and dispatch emergency services. These connected computers and the network that connects them -- collectively known as "the internet of things" -- affect the world in a direct physical manner.

We've already seen hacks against robot vacuum cleaners, ransomware that shut down hospitals and denied care to patients, and malware that shut down cars and power plants. These attacks will become more common, and more catastrophic. Computers fail differently than most other machines: It's not just that they can be attacked remotely -- they can be attacked all at once. It's impossible to take an old refrigerator and infect it with a virus or recruit it into a denial-of-service botnet, and a car without an internet connection simply can't be hacked remotely. But that computer with four wheels and an engine? It -- along with all other cars of the same make and model -- can be made to run off the road, all at the same time.

As the threats increase, our longstanding assumptions about security no longer work. The practice of patching a security vulnerability is a good example of this. Traditionally, we respond to the never-ending stream of computer vulnerabilities by regularly patching our systems, applying updates that fix the insecurities. This fails in low-cost devices, whose manufacturers don't have security teams to write the patches: if you want to update your DVR or webcam for security reasons, you have to throw your old one away and buy a new one. Patching also fails in more expensive devices, and can be quite dangerous. Do we want to allow vulnerable automobiles on the streets and highways during the weeks before a new security patch is written, tested, and distributed?

Another failing assumption is the security of our supply chains. We've started to see political battles about government-placed vulnerabilities in computers and software from Russia and China. But supply chain security is about more than where the suspect company is located: we need to be concerned about where the chips are made, where the software is written, who the programmers are, and everything else.

Last week, Bloomberg reported that China inserted eavesdropping chips into hardware made for American companies like Amazon and Apple. The tech companies all denied the accuracy of this report, which precisely illustrates the problem. Everyone involved in the production of a computer must be trusted, because any one of them can subvert the security. As everything becomes a computer and those computers become embedded in national-security applications, supply-chain corruption will be impossible to ignore.

These are problems that the market will not fix. Buyers can't differentiate between secure and insecure products, so sellers prefer to spend their money on features that buyers can see. The complexity of the internet and of our supply chains make it difficult to trace a particular vulnerability to a corresponding harm. The courts have traditionally not held software manufacturers liable for vulnerabilities. And, for most companies, it has generally been good business to skimp on security, rather than sell a product that costs more, does less, and is on the market a year later.

The solution is complicated, and it's one I devoted my latest book to answering. There are technological challenges, but they're not insurmountable -- the policy issues are far more difficult. We must engage with the future of internet security as a policy issue. Doing so requires a multifaceted approach, one that requires government involvement at every step.

First, we need standards to ensure that unsafe products don't harm others. We need to accept that the internet is global and regulations are local, and design accordingly. These standards will include some prescriptive rules for minimal acceptable security. California just enacted an Internet of Things security law that prohibits default passwords. This is just one of many security holes that need to be closed, but it's a good start.

We also need our standards to be flexible and easy to adapt to the needs of various companies, organizations, and industries. The National Institute of Standards and Technology's Cybersecurity Framework is an excellent example of this, because its recommendations can be tailored to suit the individual needs and risks of organizations. The Cybersecurity Framework -- which contains guidance on how to identify, prevent, recover, and respond to security risks -- is voluntary at this point, which means nobody follows it. Making it mandatory for critical industries would be a great first step. An appropriate next step would be to implement more specific standards for industries like automobiles, medical devices, consumer goods, and critical infrastructure.

Second, we need regulatory agencies to penalize companies with bad security, and a robust liability regime. The Federal Trade Commission is starting to do this, but it can do much more. It needs to make the cost of insecurity greater than the cost of security, which means that fines have to be substantial. The European Union is leading the way in this regard: they've passed a comprehensive privacy law, and are now turning to security and safety. The United States can and should do the same.

We need to ensure that companies are held accountable for their products and services, and that those affected by insecurity can recover damages. Traditionally, United States courts have declined to enforce liabilities for software vulnerabilities, and those affected by data breaches have been unable to prove specific harm. Here, we need statutory damages -- harms spelled out in the law that don't require any further proof.

Finally, we need to make it an overarching policy that security takes precedence over everything else. The internet is used globally, by everyone, and any improvements we make to security will necessarily help those we might prefer remain insecure: criminals, terrorists, rival governments. Here, we have no choice. The security we gain from making our computers less vulnerable far outweighs any security we might gain from leaving insecurities that we can exploit.

Regulation is inevitable. Our choice is no longer between government regulation and no government regulation, but between smart government regulation and ill-advised government regulation. Government regulation is not something to fear. Regulation doesn't stifle innovation, and I suspect that well-written regulation will spur innovation by creating a market for security technologies.

No industry has significantly improved the security or safety of its products without the government stepping in to help. Cars, airplanes, pharmaceuticals, consumer goods, food, medical devices, workplaces, restaurants, and, most recently, financial products -- all needed government regulation in order to become safe and secure.

Getting internet safety and security right will depend on people: people who are willing to take the time and expense to do the right things; people who are determined to put the best possible law and policy into place. The internet is constantly growing and evolving; we still have time for our security to adapt, but we need to act quickly, before the next disaster strikes. It's time for the government to jump in and help. Not tomorrow, not next week, not next year, not when the next big technology company or government agency is hacked, but now.

This essay previously appeared in the New York Times. It's basically a summary of what I talk about in my new book.

Read the whole story
29 days ago
Share this story

Thinking Through Male-Female Friendships

1 Share

Newton’s third law tells us that for every action there is an equal and opposite reaction. Though this law pertains to physics, it seems equally true in the realm of ideas. Recently, a renewed emphasis on the value of the Billy Graham/Mike Pence Rule as a means of protecting sexual fidelity has provoked an equal and opposite emphasis on the value of male-female friendships. To be clear, what’s under discussion here is not whether it’s okay for couples to be friends with other couples, but whether it is acceptable and advisable for a man and woman to share a close personal friendship while they are each married to other people.

I have been challenged by much of the writing about male-female friendships, I have been thinking about the topic a lot over the past few months, and I’m eager to apply it to my own life and friendships. I have observed that much of the discussion about opposite-sex friendships depends upon the brother-sister analogy that is so common in Scripture. When we put our faith in Jesus Christ and receive his salvation, we are adopted into the family of God, becoming brothers and sisters in the Lord. This relationship is a tremendous blessing and carries great significance. Addressing one another as “brother” and “sister” is not just Christian tradition, but proclamation of precious truth!

While the language of the spiritual family describes something genuine—we are bound together in Jesus Christ—we need to remember that it is also metaphorical. Metaphors are a useful means of fostering understanding, but they invariably have limitations, and we need to be careful we do not push them too far. As a kind of personal thinking challenge, I’ve been attempting to consider the brother-sister to see where I may encounter its limitations.

I have three biological sisters and enjoy close relationships with them. This closeness is not only a product of sharing genes and living our early lives together, but of spending plenty of quality time with one another and even divulging intimate details of our lives. I gladly go out for coffee or a meal with any of them. I stay overnight in their homes even if their husbands aren’t around. I get in a car with them at any time and under any circumstance. I call them up just to chat. I ask them deep and meaningful questions and even attempt to bring wisdom to bear on deeply personal matters. I deliberately seek their wisdom when I have questions about my life or marriage. I end every phone call with, “I love you.” There is a significant degree of relational intimacy between us, yet in all of it there is not the least danger, confusion, or misunderstanding about the nature of our relationship or our intentions. Why? Because we are brother and sisters. And it gets better still: no one else harbors the least suspicion about our relationship for the very same reason. Even if someone may initially raise an eyebrow when they see us together, all they need to hear is, “Meet my sister” and all suspicion vanishes.

Does this brother-sister relationship provide a valid model of what I should expect to experience with sisters in Christ? I believe the answer is a solid yes and no.

The answer is “yes” because brothers and sisters in Christ are meant to model their love, commitment, and purity on the familial relationship. Besides the hundreds of verses that exhort us to live as brothers and sisters, we have some very specific teaching on relationships: Treat “older women as mothers, younger women as sisters, in all purity,” says Paul to Timothy (1 Timothy 5:2). It’s like he’s saying, “Think about your own sisters and extend that very same level of love and purity to the young women in your church.” Well and good. However, I still believe that at some level we can push the metaphor a bit too far, and this is where we encounter the “no.” Stick with me here and I’ll show how I’ve been thinking it through.

Let’s say a young and unmarried Christian man is looking for a wife with whom he can share his life, enjoy romance, and pursue a sexual relationship. He can look out at the mass of women in the world and identify a small number of people with whom he absolutely must not form such a relationship: his biological sisters. To pursue them would be an egregious offence against natural law, federal law, and God’s law. Thus, biological sisters form the pool of people who are completely off-bounds when it comes to romance, marriage, and a sexual relationship.

Who makes up the pool of people who are in-bounds? Sisters. Spiritual sisters. Biological sisters form the pool of people whom he must not select from and spiritual sisters form the pool of people whom he must select from. A young man rightly looks toward his spiritual sisters when he wishes to begin the kind of relationship that would be grossly immoral with his biological sisters. This stands as proof that the familial brother-sister relationship only extends so far and that at some point the metaphor begins to break down. We are brothers and sisters in one way, but we are not brothers and sisters in another way.

So let’s circle back to the relationship I enjoy with my three sisters. Think about the relational intimacy we share and how it is the product of opening our lives and hearts before one another, spending lots of quality time together, deliberately saying, “I love you.” There is no danger of pursuit, romance, or sexuality. There is no danger of confusion about intentions and no danger of misunderstanding the nature of our relationship. This gives us a tremendous freedom to enjoy one another and to pursue very deep and meaningful relationships. My sisters and I can pursue and enjoy that relational intimacy at least in part because they are in the pool of people who are off-bounds.

But any other woman exists in that other pool. We may both be happily married to other people at the moment. We may both have absolutely pure intentions and desires at the moment. But that does not shift her into the same pool as my biological sisters. There are circumstances (such as the deaths of both spouses) where in the future there could still be a perfectly God-honoring pursuit, romance, and sexual relationship, something that is never the case with biological sisters. This demonstrates that these two brother-sister relationships are analogous, but not perfectly and completely so. Eventually the metaphor breaks down, which tells me I cannot use it without careful consideration and qualification. I have to guard against stretching it past its limits.

Here is what I’m driving at. The Bible lays great importance on the brother-sister relationship to govern relationships between Christians, and so should I. It should be my joy and privilege to carefully draw out the implications of that brother-sister relationship and to live it to the full, and I am convicted I need to do better here (which is exactly where I can benefit from reading the material people have been writing on living as brothers and sisters in the Lord). I must be careful not to deceive myself by mistaking avoidance for purity (to borrow Aimee Byrd’s helpful little phrase) and must not allow fear or suspicion to keep me from loving and serving women the Lord brings into my life. The brother-sister relationship has so much to teach me here. Yet it is not an exhaustive metaphor and neither is it the Bible’s exclusive word for governing relationships. I am responsible to ponder and heed it, but also to be careful not to follow it beyond its breaking point.

(Douglas Wilson has been doing some helpful writing on this and these thoughts are very much my way of working out what he has been saying.)


Read the whole story
45 days ago
Share this story

Is the iPhone XS Max 512 GB Expensive?

1 Comment

Not compared to a MacBook Pro. Interesting comparison.

Read the whole story
56 days ago
Great tweet
Share this story

Why You Should Go to Church Even When You Don’t Feel Like It

1 Share

David Sunday, pastor of New Covenant Bible Church in St. Charles, Illinois:

Friends, do you realize how vital it is to gather here together on the Lord’s Day, Sunday after Sunday? Satan loves to isolate us. This is a killer! Don’t neglect to gather together with God’s people in worship! You’re here today—but your presence here today is not just for today. It’s for five years from now. Twenty years from now. It’s for a time when you may find yourself alone in a cancer ward; or isolated from Christian fellowship in a desolate place; or in prison for your faith; or in terrible turmoil within your soul; or alone at home, in the middle of the night, after you’ve buried your loved one in the ground.

You cultivate the means of grace today for sustenance you may need way down the road.

There are seeds that are being planted today in your heart that may not blossom into full fruit until many days from now.

But your attendance in worship, your participation in baptism and the Lord’s Supper and confession and praise and thanksgiving and singing and intercession and hearing the preaching of God’s Word—it’s all being woven together by sovereign grace.

Through all these ordinary means of grace, God is weaving a tapestry of remembrance to sustain you in days to come, when your soul may be famished, when you may feel lost and alone—God will remind you then of something you heard, many years before; he will bring to your remembrance a song you had long since forgotten; a person who had taught you the Word of God; a face whose radiance in worship always inspired you; a faithful follower of Jesus who now has gone before you into his glorious presence—God will take sermons you’ve heard, and bear fruit from them in your life decades from now. You may not recall the exact content. But the good seed of God’s Word is being planted in the soil of your heart, and it will bear fruit in its season, just when you need it.

That’s why we meditate on the teachings of God in Scripture day and night. That’s why we gather in the house of God with the people of God week by week. We don’t do it just for the immediate benefit. We take the long view. We cultivate these rhythms of grace, we practice these disciplines of worship, so that when the years of drought come, we will remember: we will recall when our souls pour dry the days of praise within God’s house. And the very remembrance will sustain us.

The entire sermon, entitled “Preach the Gospel to Yourself When Your Soul Is Downcast,” is outstanding.

Read the whole story
62 days ago
Share this story
Next Page of Stories