Every weekday I go into an office, write code, joke on slack with coworkers, and generally try to improve our code base, our workflows, and our communication with other teams. In the evenings, I go home, drink tea, and conduct job search activities with my elderly cat sprawled on my lap.

Looking for a job while you already have one can be difficult, but it is a great opportunity to think about what has and has not worked for you so far in your career. I am not scrambling to find a position and I won’t take just anything. I am taking the chance to define my next career step in such a way that I will be happier, better paid, and contribute in a more significant way to my employer.

I have thrown around so many ideas and thoughts through this process that I thought it would be fun to write a quick post of the career insights that I have had over the last few months. Enjoy!

Skills are Transferable

I have something of a strange work history. I am lucky in that it has all been technical, but it is a bit unique, so I am often asked about it.

A short-ish version of my career trajectory–my education is in civil/structural engineering. After grad school I worked for a structural engineering firm and got my license in civil engineering. I left my job for family/health reasons and worked as a tutor here and there until those issues were resolved. Upon re-entering the workforce, I decided to find a software job because I had loved the coding I did in college and I liked what I had heard from my friends who worked as developers. I took some training and landed a job as a dev. After a few years of this, I got into conference speaking and learned more about developer advocacy and similar jobs. I took as many opportunities as I could to gain some skills relevant to developer relations, and I am now pursuing that as my next career step.

The above might make your head spin a bit, but this career path really hasn’t been that bad. I managed these changes (and hope to manage the next step) by identifying my skills and letting people see how they transfer to the next job. For instance, when I was working in civil/structural engineering, I may not have been writing code, but I was thinking about edge cases, developing thoughts around testing, communicating technical ideas to non technical audiences, and more. All of these have proved relevant to my current job. When I was tutoring I was managing client relationships, working one on one with people to help solve their problems, explaining how things worked in an accessible and non condescending way. These skills have been important too and I expect that they will be even more so in developer relations.

I am planning to take some experiences and traits from long before I became interested in code into my next job. These traits include being comfortable in front of crowds (thanks musical theater!) and being able to present my case (thanks lawyer parents!).

Identify the things that you carry with you that will be valuable in your career. Ask trusted friends and family what traits you bring. You might be surprised at how relevant and useful those traits are, even if they are not strictly technical.

We are All Salespeople

So to be completely frank, part of me is deeply uncomfortable around salespeople. Buying a car is the worst. I bought my gym membership online instead of going into the gym and selecting a plan with one of their salespeople. I unfollow acquaintances who get roped into multi level marketing schemes because I do not want to buy their skincare products/protein shakes/candles.

But sales, when done well, is about empathy, listening, and persuasion. In you career all three of these skills are essential.

Empathy is important because it is necessary to understand the problem you are trying to solve. This is true whether the problem is how do we deliver x,y,z to our client or how do I land this job. If you don’t empathize, you will never actually understand the constraints of the design problem or what your potential employer needs from the open position and whether that position actually suits you.

Listening is key as well. I have participated in the interview process several times at my current job. Interviews include hard questions, and when someone sidesteps an issue, or answers a different question than the one I asked, I wonder if they are scared of the hard question or if they weren’t listening carefully.  Neither quality is great. If you are not listening, you cannot address any concerns that are present, nor can you get to the heart of the issue and how you can help.

Persuasion is hard. It is far more nuanced than simply winning an argument. It is inviting someone to try your point of view and see if it improves things for them. To make that invitation, you need to have built some trust. To preserve the trust that you have built, you have to realize that the answer could be no.

While interviewing, I desire to empathize with my potential employer, to understand their needs and the challenges ahead of them. I want to listen to their questions and concerns, and address them as honestly and reasonably as I can. I want to help the employer get to know me a bit, so I can cast a vision of what I would be like in the role. Hopefully they can picture it too, and they can ask themselves if that vision is inline with what they want from their new hire. It is not easy to sell this idea, and the answer will be no most of the time. But I count it as a success (albeit a smaller one than actually landing the job) if I can get the employer to honestly and truly consider what I would be like in the position. Someone is going to buy this vision, I just hope to be able to present a full picture to as many potential employers as I can.

You Can’t Optimize Everything

YOU CAN’T OPTIMIZE EVERYTHING. There are a lot of factors that go into your job. Where is it? What sort of hours are expected? What is the pay? What are the advancement opportunities? Is there/how much travel is involved? What are you spending your time doing?

In my first career, I worked in structural engineering. I am still a licensed civil engineer. There was an inherent trade off that I had to balance when selecting structural members. As the strength of the beam increased, so did the weight. At some point, a stronger beam isn’t actually stronger because the added weight offsets any strength increase. The ideal beam balances these concerns for the given application. You cannot optimize for both strength and weight.

The same is true for your career. You can’t optimize for everything. Where are you willing to compromise and where are you not? I recently had a promising interview. When I had applied for the position, it was listed as remote (and indeed, most of their devrel team is remote). The position was a great fit for me in several ways–what I would be doing day to day, I liked their product, etc, etc. The hiring manager eventually decided that the role really had to be in SF, otherwise performance would likely be compromised, so we didn’t continue the interview process. This was sad to me because I really liked the role and had been getting positive feedback. But no SF is currently one of my non-negotiables. So we hit an impasse and that was okay.

Currently I am most interested in what I am doing day to day (developer advocacy or similar, not a strictly software job), where I am doing it (basically anywhere but the bay area, but the PNW preferred), and what my employer is like. I have expectations around some of the remaining things (like a salary floor I won’t go under) but I know what I am willing to talk further about and what I am not.

These may change a bit as my job search progresses and I think it is important to re-evaluate every once in a while. Don’t let the perfect be the enemy of the good.

Negotiate!

Pay, vacation, hours etc. It is much, much easier to ask for things before you sign compared to after they have you. Your largest pay increases are likely (though not definitely) to happen upon switching jobs. I was fairly happy with how I negotiated before my current job, but that was way easier and more productive than any negotiations I have had since then, so do what you can once you have that offer.

Let Someone Else Tell You No

One of my favorite things in the whole world is running. I also happen to not be very good at it. I am not fast by any means but I really enjoy running and extra enjoy running very long distances.

A few years back, I ran my first marathon (26.2 miles). I was in the back of the pack (it is more economically efficient, if you run slow you can enjoy the marathon for more time). The race directors want to see everyone finish, but they also are obligated to reopen the roads and they want everyone to be safe.

Right around mile 23 there were whispers amongst my fellow turtles that they were going to start sweeping (pulling people from the course). It was pretty disheartening to hear and some people were struggling to continue. I decided that I would not take myself off the course. I would comply with a race official who told me that he was sweeping me, but I was not going to sweep myself. So I kept going and damn it, I finished the marathon! I also ran the entire final mile grinning ear to ear.

If there is something you want, be it a job or becoming a marathoner, just don’t count yourself out. Accept being swept graciously if it happens. Thank the interviewer for their time and for their consideration even when the answer is no. But don’t pull yourself from the course when it is something you really want. Toe the start line of the race. Submit your resume even though you might not fit every criterion listed. Let someone else tell you no because they just might say yes instead. And then you are given a medal, a banana, and some gatorade or a kickass new job. Whichever.

 

From “An Eye for an Eye” to Gatekeeping

If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then that builder shall be put to death. This is a law from the Code of Hammurabi, written almost 4,000 years ago. If it kills the son of the owner, the son of that builder shall be put to death.

This code is the earliest known instance of construction laws and it can be thought of as basically a grisly series of if/then statements. It reflects the structure of society at the time–meeting out different punishments for offenses perpetrated against the offender’s equals than their inferiors. Taking the lives of people connected to the offender! It is in many many ways shocking and harsh and it really shows it’s age.

My name is Hayley Denbraver and I am a web developer and an aspiring developer advocate. In an earlier chapter in my life, I worked as a structural design engineer and got my professional engineering license in Civil Engineering from the state of California. I even have a stamp with my name on it, very official.

I can say, with absolutely no caveats, that I am glad that modern construction law doesn’t look like the code of Hammurabi.

But I think the code of Hammurabi has something interesting and relevant to say, even today. The law is brutal, but there is an undeniable sense of accountability. And this is where, in my previous field, the idea of engineering ethics started. In violence and absolutism. And more than 3,000 years ago.

Fortunately my former discipline didn’t stay there. The germ of responsibility and accountability had begun, but do you want to know how it sprouted and flourished? Disasters mostly.

All were horrifying, but many make for interesting reading–for instance, did you know that in Boston in 1919 an enormous tank filled with molasses failed, flooded the town, and left everything sticky for months? It also killed 21 people. Today on the site of the engineering failure, there is a plaque that reads: On January 15, 1919, a molasses tank at 529 Commercial Street exploded under pressure, killing 21 people. A 40-foot wave of molasses buckled the elevated railroad tracks, crushed buildings and inundated the neighborhood. Structural defects in the tank combined with unseasonably warm temperatures contributed to the disaster.

This disaster and the resulting class action lawsuit lead to the first licensure laws in the United States.

So construction law and engineering responsibility moved from an ‘eye for an eye’ philosophy to one of gatekeeping. And the gate you must pass through is licensure.

Let’s Talk Licensure

So what is licensure and why does it matter? Professional licensure protects the public by enforcing standards that restrict practice to individuals who have met specific qualifications in education, work experience, and exams.

We are going to talk a bit about licensure, not because it is the same as ethics, but because it is a system of formalized responsibility. And taking responsibility for your work and how it impacts others is a pretty good place to start, whether this responsibility is formalized or not.

In order to get licensed, I completed my undergraduate studies in Civil Engineering from an accredited university. Additionally, my masters degree in Structural Engineering counted a year towards my work requirement. After that I worked for a year and a half to finish my work requirement. I then needed a few licensed engineers to vouch for me. Finally, I had to pay more than a grand to sit for a three part, multi day test that many people need to take multiple times to pass.

Now, just because I worked for a bit , took some exams, and jumped through some hoops doesn’t mean that I am a good person. But that isn’t really the point of licensure. The point is that as a licensed civil engineer, I had a stake in the outcome of my work (malpractice can result in losing my license or in prosecution depending on the breach), I was accountable to the general public, and I could be censured by my professional community if I operated outside the bounds of ethical practice. Licensure also ensured that I understood the basics of ethical practice, because I was tested on it, and because my accredited degree required an ethics course.

So what about Software Engineering?

So how does all of this compare to my experience writing code and having the title “Software Engineer”.

Well, to start, the title “Software Engineer” doesn’t mean much. Anyone can call themselves a Software Engineer with abandon. When I was nearing the end of my coding bootcamp, we were issued business cards that had our name, contact info, and the title “Software Engineer” on them. Obviously, these served a practical purpose for us while we were job searching and additionally, our instructors wanted to instill confidence in us. However, in no way could you do something like that with the title “Civil Engineer”, which is a title protected by law. You can’t just print “Civil Engineer” on a business card and set up shop any more than I could apply the title MD to myself and start treating patients. The title “Software Engineer” might mean something within the corporate structure or for your career growth, but it doesn’t imply anything official about your education, work experience, or responsibility towards the public.

Secondly, on my development team, we are pretty well split between people who are self taught, bootcamp grads, internally trained developers, and people with a computer science degrees. This sort of breakdown would make zero sense in a civil engineering office. I realize not every workplace is going to have a group of developers this diverse, but many many offices have developers that fall into a category other than “got a BS in Computer Science”.

Third, my work is evaluated by my peers and possibly my team lead before it is deployed, but it isn’t reviewed by any exterior party. It isn’t available to the people who use our service. It isn’t retained anywhere public. This is a very different process compared to structural plan review, where the city, county, or a governing department is involved . Version control and pushing code to github is far from the stamped structural plans of my previous career.

So you might be thinking, “Okay, so your new career is different than your old one. Why should it be the same? It is a different field, after all” and that is a fair point. And within it, there is a kernel of truth. Not every software developer is going to be writing code that has the capacity to negatively impact the public if they act unethically or if they lack a certain level of skill or knowledge. It is hard to argue that all software developers fall into this category, given recent data breaches and the examples we see in the news of people using a platform inappropriately.

I want to talk about one final difference between software development and civil engineering. It is a difference of culture. Software is open in a way that civil engineering cannot be under the current system. Knowledge is shared much more freely, there are many more accessible opportunities for learning, and there is more varied work for a varied population of developers. And this is really exciting! I don’t want this to end, and for more reasons than that I came from a non-cs degree background.

So What is Next?

My personal opinion is that one way or another, our industry will eventually see the adoption of an ethical framework. I believe that the discrepancies between how these fields are practiced will shrink.

The question is whether this will come from within the industry, or whether it will come from external pressures and sources. Will it be something we adopt or something that is imposed on us? Can we do it for the right reasons, or will it be a reactionary response to a disaster? Can we create something that both protects what is good in the industry, but provides increased accountability to the public?

I don’t really have answers to these questions. 100% overhauling how we approach our work is too big for a minimum viable project, in my opinion. So I want to propose a few ideas that we can start with, and then iterate from there.

First, we need to promote ethical literacy in the same way that we promote technical literacy. We are expected to keep up with our technologies and tools. It is not too much to ask that professionals have a basic grounding in ethical conduct.

Second, we need to take review, both internal and external, more seriously. Think about your team and how they release code. My current team has some very basic guidelines in place. Although you can’t release your own code and code can’t be merged if tests aren’t passing, there is some rubber stamping that goes on. I think we can do better. If a project has the potential to impact the health and safety of the public, I believe that it is reasonable to have some external code review. That way, other fresh eyes are looking at the problem and may spot issues to which you are blind.

Third, we need to improve communications between stakeholders and the team. One of the things that I miss about my old career is that on issues of safety I had veto power. Architect, client, or contractor wants something that is unsafe? DENIED. In most civil engineering firms there are fewer layers between the engineer and the client. In software you may have to communicate that something is a bad idea to your product manager, and damn it you are ruining the roadmap, and whoops sales already has contracts out, and now we are behind. Bringing increased ethical awareness into our work requires buy in from more than just you, an individual developer.

So those are some of my suggestions for good first steps. But remember, it is not enough to say, “Oh yes, good idea, I will talk to my team and get it squared away.” Companies need to put time and resources behind engineering ethics efforts and take work that devs and others do on this as valuable, not just “nice to haves”.

Acts of God and Sticky Shoes

To close, I want to return to the story of the Boston Molasses Flood. To recap: tank failed, area flooded with molasses, 21 people died, massive lawsuit, the catalyst for licensure in the united states.

A similar event had occurred in 1814, around 100 years prior, in London. There was a similar structural failure and nearly 1.5 million liters of beer were spilled. It killed eight people, including five people who had been gathered for a wake. It also had resulted in a trial, although the engineers weren’t held accountable because the disaster was ruled ‘an act of God’.

I ask you, why do you think that the tech industry has so far largely avoided things like licensure and accountability for the impact of their work? I think the answer is that failures are seen as an “act of God”. We wouldn’t phrase it that way today, but the thinking is similar. For much of the public, computers are somewhat magical and when the people don’t have even an abstracted level of understanding of how something works, it is hard to demand accountability.

The Molasses flood a hundred years later played out differently and I think that is for two reasons. First is that we had progressed 100 years in science, education, etc. That is great! The second reason is a little more sticky.

Bear with me here. Imagine you are a citizen of Boston in 1919. Even if you didn’t know anyone injured or killed, a few weeks later you are walking down the street and your shoes make a squelching sound because of the molasses residue that is EVERYWHERE. You don’t sit down on the train because you don’t want to ruin your clothes. The seats are sticky too. You have wandered into the Molasses swamp from Candy Land and there is no escape. The public couldn’t forget. They were forced to engage with it repeatedly. Every sticky step, you can’t forget. Change is mandatory.

That is what I want you to take from this post. When you go to your workplace tomorrow, imagine you are walking down the hall and your shoes are squelching. You sit down to your keyboard and it is sticky. Could you forget that or would it stick with you? Write your code, but remember that you are working for people, and that they deserve your care. May your responsibility towards them stick to you like tree sap, super glue, or molasses.

Sources:

https://ncees.org/

Code of Hammurabi

Boston Molasses Flood

London Beer Flood

Welcome!

I am glad you made your way here for the inaugural blog post. Have a party favor! Take a seat and get comfy. There are chips and dip to your left.

What’s Up

I am currently up to my eyeballs in planning for my European Python Adventure (TM). This will hopefully include visiting some family in the Netherlands, before hanging out on Baker Street in London, and then taking an sleeper train to Edinburgh for EuroPython.

I am a speaker for the event and will be giving a talk called: “Recursion, Fractals, and the Python Turtle Module”. Look for a blog post once the talk has been given! This talk should be a good mix of fun, information, and code.

On my way home I am flying to Seattle (aka my favorite city and potential future home depending on how my job search goes) and will be giving another talk at Go Northwest.  Seeing as they use Go, they aren’t so much interested in my Turtle talk. I am presenting on engineering ethics, from my unique perspective as a licensed civil engineer. I am shooting for engaging, not guilt-tripy.

I am in the beginning stages of a job search. The last time I did this was for my first job as a developer and was three years ago. All I wanted was a foot in the door, and I got that and many other lovely things–like an awesome team. This time around, I am shooting for something very specific with regards to title, responsibilities, and location. (Basically I want to move into the developer relations space and I would love to be doing it in the Pacific Northwest!)

Code and Such

At work I am busy helping our Quality Assurance lead set up her machine and poke into our code base a bit because she will soon be writing code to solve the data problems that she faces. She has worked with Python before, but not in large scale projects or in a team environment. I am her designated contact on the dev team and we are probably going to do some pairing as she begins to commit code.

On the personal coding side, I am going to be writing some turtle code to correspond to my talk for EuroPython.

Something Nice

I aim to please, always enjoy finding gems on the internet, and love to share. In that spirit, I present to you my current favorite corner of the internet– The Golden Ratio. This bunch of Golden Retrievers are adorable, funny, and sweet. Their person is a Computer Science professor who runs marathon. I especially like their podcast and youtube channel.  You’re welcome.

---

Until next time, thanks for joining me for my inaugural blog post.