Forem: Erica Tanti

You are an archaeologist (5 tips for navigating legacy systems)

Erica Tanti — Wed, 06 May 2020 16:00:00 +0000

You are an archaeologist. When you’re at school building your own greenfield projects by yourself, this is a skill you don’t get to learn. However chances are, when you start your developer career, you’ll be working on a project which has been around for some time. This means you are navigating through a system built on layers and layers of commits by different people. You probably have partial knowledge about the thing you’re excavating. And you need to be careful not to break anything.

Here are some tools for your toolbox to help you be a better archaeologist.

1. Excavate the git history

I learnt this one early on in my career, and it’s one of the number one tools in my toolbox to this day - Excavate the git history (only when I started, it was SVN 😬🤣).

What should you be looking out for?

Read the commit messages: The commit messages are (hopefully!) going to help you look into the intent behind the code, or at least their changes. Does it have an issue number which might provide more context behind the change?
How long ago was the specific piece of code you’re looking at changed (so for example, that specific method)? How often was it changed? Is it one person, or many people? When was the first commit? This will tell you the story of the layers of the code and how it all evolved over time - or didn’t, which raises a whole other host of questions.
Look at the authors - is there anyone you can reach out to with any questions you might have?

2. Divine meaning through tests

Hopefully the code is tested, and hopefully those test names have some kind of format. For example, the format I generally tend to use is MethodName_StateUnderTest_ExpectedBehavior. Small (unit) tests can help you understand how a specific method or class works. Larger tests (like black box tests) help you understand what is happening at a feature level.

3. Search the archives of your documentation

The trick here is knowing where documentation may hide. Varies from project to project or company to company. Some examples of documentation to look out for are READMEs, Wikis, API documentation (for people integrating with the API), formal specifications documents and user guides. Just because the documentation wasn’t intended for you (as a developer), it doesn’t mean it isn’t useful. Often understanding a user’s perspective can be just as valuable, especially if you don’t have any understanding of the product or feature and its use.

4. Run the code and check (or add) logs

It might sound primitive but sometimes the best or only way to understand a piece of code is to run it. That gives you what’s called a “black box” understanding, where you don’t know anything about the code that is running. To turn that into a “white box” understanding, look at the logs to see which pieces of code are being exercised when you use certain features. If you are trying to understand a specific piece of code, you might need to add more detailed logs to get more information! It’s then up to you to figure out which logs should be committed, and which were just useful to help you to understand what was going on.

5. Don’t be afraid to get your hands dirty

The great thing about being a developer is that, unlike an archaeologist, you get a trial run. You can mess up the archaeological dig, make a bunch of changes to learn, and then stash everything and pretend like it never happened. I find this really helpful when I can feel myself getting into analysis paralysis.

So start typing! Sometimes it’s nice to get right to the refactoring - extracting and renaming variables and methods to make the code more readable. If the code is so difficult to understand that you really don’t know where to start, an easier step can be writing comments to explain what (you think) the code is doing, or leaving questions which you’ll hopefully be able to answer later.

It might seem like a waste of time to start making changes when you’re not sure if it’s the right way to go, but sometimes you’ll never know if it’s the right way to go without trying to make the changes!

Happy digging! What are your favourite legacy code navigation tips? 💭

Erica reads “Accelerate”

Erica Tanti — Tue, 28 Apr 2020 06:45:00 +0000

Anyone need a book recommendation? 🙋🏻‍♀️ Today I’m going to talk about Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren PhD, Jez Humble, Gene Kim.

Who should read this book?

“Accelerate” is a book full of practical, peer-reviewed advice on how to be more successful at building software. Therefore I’d really recommend it to the following types of people:

👩🏽‍💼 Decision makers who want to have scientifically backed data to make their decisions to change and improve their organisations.
👩🏻‍💻 People who code and want to understand how to change and improve their code processes to deliver measurably better software.
👩🏾‍🔬 People interested in research techniques and data science especially applied to building better technology organisations.

Why should you read this book?

If you’re usually one to skip the foreword (or in this case, forewords) and make your way to reading the main portion of a book, in this case I’d say - don’t! Reading Martin Fowler’s foreword really put me in the right mindset to understand exactly why this book is valuable. Also, it’s just plain hilarious 😂.

Whilst I know that you’re definitely going to read the foreword for yourself now I’ll just summarise: Fowler explains his journey from first reading some of the “2014 State of DevOps Report” (which is also written by the authors) and wanting to “toss it with great force into the rubbish bin” 🚮 to being convinced that there was real analysis behind it, even more than some academic papers.

I agree: If this book were just based on opinion or purely anecdotal, it wouldn’t be that impressive or at least widely applicable. The fact that it is peer reviewed research gives substance to previous discussions on what should be best practice in the lean and devops space.

When should you read this book?

Personally I found that when sitting down with this book, it was important to be very focused. In “Part I: What We Found” especially, the book is densely packed with information. It truly felt like each paragraph (if not each sentence) contained nuggets of interesting information to absorb and reflect on.

I bought this book on Kindle and found that it was very helpful to highlight the sections which stood out to me, or which were surprising. This both helped me to focus, and to be able to turn back to what I found to be the most interesting points to reflect on further. If you buy this in paper form, I hope you’re not too afraid to ruin a book with highlighter ✍🏻!

What did I learn?

As I mentioned previously, the book is packed with interesting insights. I’ve picked out two which struck me most at this time, being most applicable to me right now as a software engineer. This means I’ve not focused as much the equally insightful culture and leadership content.

🚢 Ship ship ship

Whilst it wasn’t news to me that continuous delivery improved delivery performance, what Chapter 5 “Architecture” highlighted to me was exactly how much it affected performance, especially in large organisations. It really made me more conscious to try and deploy my code at least daily, and to ask myself what I can improve to enable myself to deploy daily when I was prevented from doing so.

👿 Bureaucracy is not (necessarily) evil

I love it when a book challenges my worldview, and Chapter 3 on “Measuring and Changing Culture” certainly did that. The chapter discusses applying the paper “A typology of organisational cultures” by Professor R Westrum to technology organisations. Whilst the main takeaway of the chapter discusses the efficacy of generative cultures and the importance of information flow, I was struck by a few paragraphs which were more of an aside.

We should emphasize that bureaucracy is not necessarily bad. As Mark Shwartz points out in The Art of Business Value, the goal of bureaucracy is to “ensure fairness by applying rules to administrative behaviour […]”

My experience tends to be that many people in this industry are allergic to “rules”, but the point made that some rules “remove arbitrariness” and helps prevent “discriminatory treatment” will ring true. From personal experience, for example, having performance frameworks tend to be fairer because all parties know what goals need to be met to get to the “next level”, rather than it being arbitrary.

Summary

I really enjoyed reading Accelerate. So if you build software, or work with people who do, I encourage you to take a quiet couple of afternoons to read through it (ideally with a trusty highlighter). If you do I’d love to hear about your key takeaways!

The 5 Kinds of Laptop Owners - Sticker edition

Erica Tanti — Tue, 31 Mar 2020 10:29:00 +0000

Disclaimer: This post is just for laughs 💕

As software engineers, the machines we write code on becomes an extension of our identity. Whilst with desktop machines there are many ways to make your setup unique, with laptops, your options are a little more limited. And that is why many developers turn to stickers to make their machines unique. Here are the 5 Kinds of Laptop Owners - Sticker edition:

1. The #NoStickers club

This person has no stickers on their laptop.

This person is either:

a remotee who doesn’t get to see other engineers IRL very often
someone who exclusively works with people who stick stickers on their laptop
someone who will one day open their laptop only to find they’ve swiped their colleague’s machine by mistake

2. The Minimalist

This person has only a few stickers on their laptop, typically one sticker covering the logo.

This person either:

doesn’t believe in a lot of worldly possessions
very restrained
runs some kind of YouTube show where their laptop is on video, and they think that by covering the logo we can’t tell what brand of laptop they own
has recently gotten a new laptop and needs to get their sticker game on

3. The Classic Laptop Owner

This person has a laptop with the standard number of stickers on it. The stickers do not overlap, and have been curated over time.

This person either:

enjoys the aesthetics of a nicely decorated laptop
is a goody two shoes who conforms to social norms

4. The Overlapping Stickerer

The great debate - what do you do when you run out of room for new stickers? Do you stop sticking stickers on your laptop, your masterpiece complete? Or do you start overlapping the stickers 😱.

This person either:

is in need of a new laptop!
is a conference speaker who receives too many stickers
someone who cannot be bothered to remove old stickers when they fade away and replace them with new ones

Either way, you can tell this person’s history through the layers of stickers, like the layers of an ancient archaeological excavation site.

5. The One with the Laptop Stickers INSIDE their Laptop

You thought we were done? You are so wrong… there is one more type of laptop owner, and this is the strangest one of them all… The One with the Laptop Stickers inside their Laptop. These people are a rare breed, but they do exist.

This person either:

uses their laptop as a desktop, always in a dock, never actually using their keyboard
thinks out of the box

So the question is… What kind of laptop owner are you? 😄

Don't be a mentor, be a sponsor

Erica Tanti — Thu, 05 Mar 2020 11:05:21 +0000

“Mentors talk with you. Sponsors talk about you.” — Heather Foust Cummings, Catalyst Research Center for Equity in Business Leadership

A little story...

9 years ago I started my first tech summer internship. I was so excited. I got placed in the quality assurance team and wrote automation tests. Whilst I enjoyed testing, during my internship I really wanted to experience being a software developer to see which I liked better. A month into my internship, my manager held a meeting with me and asked me if I would be interested in moving to a development team.

It was many years later that I learned the reason why I got asked to move to a development team. A colleague had spoken to my manager and let my manager know that they were impressed by my work and by my enthusiasm. They knew I wanted to try development, and suggested to my manager that I move to their team.

This is one of the earliest examples of sponsorship I remember experiencing.

Why mentorship isn't enough

To get the full picture as to why mentorship isn't enough, I recommend reading and/or listening to Why Men Still Get More Promotions Than Women in the Harvard Business Review. To summarise:

Our interviews and surveys alike suggest that high-potential women are overmentored and undersponsored relative to their male peers—and that they are not advancing in their organizations. Furthermore, without sponsorship, women not only are less likely than men to be appointed to top roles but may also be more reluctant to go for them.

Telling your mentee how you got to where you are doesn't translate into your mentee being able to follow your footsteps. It's unlikely that the exact same opportunities that were available to you are available to them. You were in the right place in the right time, and to add to that hopefully you didn't have to deal with glass ceilings, conscious or unconscious bias and impostor syndrome. So how can your mentee follow in your footsteps? The answer is, don't be a mentor...

Be a sponsor

Sponsors don't just talk to you, they help you get there. Now you've understood why sponsorship is valuable, you might be asking yourself, "How can I be a sponsor?".

📢 Amplify what someone is already doing

In the literature, a sponsor is generally described as having to be "senior". Having a "senior" sponsor is great, but from my experience and from my story above, anyone can be an amplifier. When you see someone do something well, don't be quiet about it. Make sure that everyone (or the right people) know about it so they can be recognised for their achievements.

🤝 Make introductions

Early in my 20s I read Meg Jay Ph.D.'s book The Defining Decade . This was when I first learnt about "weak ties". The term was first coined by sociologist Mark Granovetter and describes people who we know distantly, like friends of friends. Weak ties know about opportunities we don't because they move in a different circle of people. As a sponsor you can make introductions to connect people who otherwise would never have met, which might lead to opportunities that never would have happened otherwise. (Find an excerpt of that chapter here.)

🧗🏻‍♀️ Help them stretch

If you want to perform the ultimate act of sponsorship, give someone "Stretch Opportunities". The whole thread by Mekka Okereke is a must read, but to summarise:

// Detect dark theme var iframe = document.getElementById('tweet-1218941824502386688-80'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1218941824502386688&theme=dark" }

I am a great believer that people learn and grow by doing, much more than by hearing how other people did it. Apart from being an opportunity for growth, stretch opportunities serve to prove what that person is capable of, in a world where potential is not enough.

Finally

Thank you to my sponsors who believe in me, who lift me up and push me forward to reach my full potential. Being a sponsor takes courage, but actions are louder than words.

About me 👩🏻‍💻

Hi I'm Erica and I've been working in the software industry for 9 years and have been coding for 15 years. In my career I've worked predominantly as a Backend Java Web Developer, but I'm not afraid to do whatever is needed to get the job done, from Frontend to DevOps. I love building products and understanding what I'm building and how to make it better. I ask a lot of questions. I love working in a team. I am often glue. When I'm not coding, I love reading, speaking (I'm a Toastmaster!) and travelling.

Rewrite 🖋 or Refactor 🧹? 10 questions to ask yourself before you decide.

Erica Tanti — Thu, 27 Feb 2020 20:34:27 +0000

The code is horrible. Looking at it makes you want to tear your hair out. Something has to be done! The question is, what are you going to do?

You have two options:

You either rewrite and replace it, building a whole new sub-system which will eventually result in the old version of the code being deleted.
Or else you refactor it, i.e. applying a series of small behavior-preserving transformations, each of which "too small to be worth doing". However the cumulative effect of each of these transformations is quite significant. (Refactoring - Improving the Design of Existing Code by Martin Fowler, with Kent Beck)

The question is, which do you pick? Your heart says "Rewrite it, this code is beyond hope!". The internet says "Refactor it, rewriting is evil!". What should you do? The answer is, as it often is, "it depends".

Here are my 10 questions to ask yourself to decide whether to rewrite, or to refactor:

№	Question	Rewrite	Refactor
1.	How much time ⏰ do you have? If you start rewriting, are you committed to finishing it?	Lots of time	Not a lot of time
2.	Do you have the right people 👩🏻‍💻👨🏽‍💻👩🏿‍💻👨🏼‍💻 available to make this change happen? (People with backend/frontend/tech ops etc skills as applicable)	Yes we do	No we don't
3.	How much of the system as a whole 🌐 are you rewriting?	A small part or a specific domain	The whole system or most of it
4.	What is it about the code that is bad 🗑?	The whole design	The way it's written
5.	How often do you predict 🔮 (hopefully know) this code will need to change in the future?	Very often	Not often
6.	How mission critical and/or valuable 💸 is this feature or domain?	Very valuable	Not very valuable
7.	Do you understand 🧠 the existing code? Do you know in detail what it does? Are the requirements clear?	Yes	No
8.	Is it just the code that is bad, or do you also need (not just want!) to make changes to the technology stack 🤖 being used?	Technology	Just the code
9.	If you had to rewrite it, how long will it take you to ship 🚢 the first part of your rewrite to production, with actual people using it?	A few days, a couple of weeks max	Months, or even years
10.	Why are you doing this? No really: Dig deep and be honest! I'll wait 💅🏻.	I believe this is the best choice	I hate this code & my ego thinks I can do better

Here's the catch: If at least one of the questions above resulted in you picking an answer in the "refactor" column, hit the brakes on that rewrite! The risk of refactor is much smaller than a rewrite. The cost of a rewrite gone bad are immeasurable.

Does this mean you should never rewrite code? No! What it does mean is that if the conditions are not right you should go back to the drawing board and make do for now until the conditions are right. Sometimes a rewrite is truly the better option, but avoid doing it just because it sounds like the easiest or most appealing.

What do you think? Are there any questions you ask yourself that I have missed?

Originally posted on: https://ericathe.dev/blog/2020/02/27/rewrite-vs-refactor/

HTTP Caches - I read RFC 7234 so you won’t have to. Part 1: The Basics

Erica Tanti — Sun, 16 Feb 2020 14:36:20 +0000

What is an HTTP cache?

An HTTP cache stores the responses of HTTP requests made over a network in a local store. The next time the cache receives a request matching the local copy of the response, the cache can return that instead of making the network call again. This reduces the response time and network bandwidth consumption on future HTTP requests.

What is RFC 7234 and why should I care?

RFC 7234 is an Internet Standards document for Hypertext Transfer Protocol (HTTP) defined by the Internet Engineering Task Force (IETF). RFC 7234 defines how a cache should be implemented internally.

Although most developers won’t have to implement an HTTP cache, it’s useful to know what’s happening under the hood, because as a Web Developer there will come a time when you’ll find yourself asking, “Is this being cached, and how do I make it stop?” 🤔.

If you’re implementing client side code then you can send cache control headers in a request to influence whether you’re going to get information from the cache or not, depending on various criteria.

If you’re implementing server side code then cache control headers sent in the HTTP response inform the cache on how long it is safe to store the request in the cache. If as a server you don’t provide any cache control headers, the cache uses heuristics to estimate what can be cached, and for how long.

Where are these caches?

Caches fall into two types, private caches, dedicated to a single user, like the one in your browser, and shared caches, which are used by more than one user, like caches at your ISP, CDN or server side caching. In the latter case, there are certain extra restrictions on what is cached, because you don’t want to be serving user specific data to other people by mistake 😬.

What are the disadvantages of caching?

The most obvious disadvantage of caching is that you want to retrieve the latest information from a server, but somewhere along the way your request keeps getting cached.

The second less obvious disadvantage has to do with security. Bugs 🐛 or vulnerabilities in caches can result in a whole host of problems. These include:

Since a large number of requests and responses are saved in caches, if the cache becomes compromised, there’s a lot of a user’s history available.
A compromised cache can be injected with malicious payloads.
Sensitive/private data can end up being cached due both due to bugs in the cache or misuse of caching headers.
Or simply someone being able to tell that a website has been visited previously because a page takes less time to load, because it has been cached.

The potential gains for attackers are multiplied when they manage to target shared caches, as this allows them to reach multiple users.

Want to learn more? Some great resources on caching from my research

The original RFC 7234 itself - https://tools.ietf.org/html/rfc7234
An updated version of RFC 7234 with inline errata - https://www.rfc-editor.org/rfc/inline-errata/rfc7234.html
Mozilla's documentation explaining Cache Control https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control and https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
Mark Nottingham's super comprehensive Caching Tutorial - https://www.mnot.net/cache_docs/

Originally posted on: https://ericathe.dev/blog/2020/02/16/caching-part1/

Reasons to Write 📝

Erica Tanti — Sun, 02 Feb 2020 22:46:17 +0000

Note: This first blog post is a reminder to myself as to why I have decided to write a blog. I hope it's helpful to other people here also!

I have been meaning to start writing a blog for some time and finally this is the first post! My SMART goal is to publish a post every other week. My reasons to write are:

👶🏻 For my past self: To share things that I have learnt with the developer community, especially when I tried to find an article to help me and didn't find exactly what I needed.

👩🏻‍💻 For my present self: If you cannot explain something, you do not understand. Although it's uncertain who actually said this this quote definitely resonates. I learn better when actively taking notes and trying to explain things rather than simply reading. I hope that by explaining to others, I also benefit myself indirectly.

👵🏻 For my future self: As developers we are constantly learning, and only a finite amount of information can actually fit into a single brain. I want to write so that my future self can refer back to what I have written and easily relearn what I had learnt in the past.

I've made a conscious effort here to have the goals focus on myself and what I can control (known as process goals), rather than who or how many people read my posts or other "success" factors, because even if no one reads what I write, the writing itself is worth it.

If you're interested in even more motivational words, I was super inspired by:
to finally start writing and define my "why", and

A Dozen Ways to Make Time

Practicing Developer ・ Jan 14 '20

#productivity #career

to actually make the time to do it (this post was written in the small moments of my week in between doing other things).