Category: impactful-engineer

The Cycle Of Creating Software

December 5th, 2020
As software engineers, our job is to create useful services for other humans or other services that depend on our services.

In the idealized world, we write software, deploy, and move on.

In the real world, we have to think about
- Writing software
- Debugging our own software for bugs
- Testing it locally for the change, but also for any dependencies
- Writing test code to validate our change (this sometimes is bigger than then change we made)
- Submitting it for review and address the feedback from other engineers, much like writers and editors
- Deploying it to a test and staging environment to show others
- Deploying it to a canary environment to a small set of customers to exercise it, watching metrics to ensure our software worked as expected. Working with the System Reliability Engineers, make sure the impact to customers is as expected.
- Writing monitoring for our software change
- Being on call to support our change and changes made to other engineers on our team and beyond our team.
- Deploying our changes to the production environment where live customers can interact with it.
- Collecting feedback and creating and managing a backlog for future changes.
- As the systems grow larger, the original code that we wrote may be considered a legacy of technical debt as the environment changes. There could be security, scale, coverage concerns that need to be addressed.
This is the world of a software engineer beyond just writing code. As an engineer writes more code, they have more ‘legacy’ to support. For an engineer to be effective, what they create needs to be continually groomed and tend to. How they enable others to help is an important factor to help them scale. How they enable their future self to look at code they had written 1-2 years ago can be done through rigorous automated testing and up to date document and knowledge sharing.
link: Effective_Engineer Summary

April 17th, 2020

https://gist.github.com/rondy/af1dee1d28c02e9a225ae55da2674a6f
Pick one, and go deep

March 29th, 2019
As an engineer, I’ll give you 4 attributes to define your work to choose from
- Ownership
- Customer focus
- Data driven
- Cadance
You have to chose at least one of these to drive your work. Pick one and focus.
What does Tony do in Engineering Productivity?

March 16th, 2019

My full time job is to work on engineering productivity.

Often folks ask me what I do every day / every week?

I often tell them what I’m working on this quarter.

Quarterly Focus

Well, the first quarter in 2019, my focus is on creating coding labs and content for new engineers that join Splunk so they understand what tools are available for them that is uniquely only available at Splunk.

Training New Hires

Every week, I will meet with all newly hired engineers for 2 hours and show them the tools available to them. Every 2 weeks, we will meet for 6 hours and they will do the coding labs we have created for them. I will likely talk with them for 30 minutes about the products at the company, the community, my own story at Splunk and what makes for an effective and impactful engineer. What is the culture in the engineering organization?

Tech Talks

On an ongoing basis, I will solicit internal and external folks who have worked on interesting problems to present during our weekly tech talks. The purpose is to share the work so other might learn and make use of the work themselves. Or the talks are to inspire them to think bigger and beyond their daily work.

Listening

Anther part of my work is just listening to engineers and they may reach out to me to help them get their work done. This could be a wide range of topics. It could range from just looking for the name of someone who could answer a technical problem. It could be just brain storming with me about a problem they have in finding a solution to replicate a problem with a particular mobile app. It could be helping them finding a solution when they feel overwhelmed with too many meetings.

Systemic Solutions

When I listen to an engineer on a specific problem, I often would try to help them solve the initial problem. Make sure they are unblocked. Then my real job kicks it and I need to figure out whether this is a more systemic problem. I would reach out to other engineers and other engineering managers and figure out who else has the same question or problem. Or I would write a document so that others could benefit in the future. I could also create a backlog EPIC so the team of 3 engineers might brainstorm with me on a more longer term and thorough solution.

Non Technical

Still to be written, Saturday badminton awaits

Mentoring

Still to be written, Saturday badminton awaits

Engineering

Still to be written, Saturday badminton awaits
Standing your ground

March 14th, 2019
Two and a half years ago, when I joined my current company I was attending a new hire training and the last slide showed a very long URL to a document that we were suppose to remember for more information.

I asked the presenter whether there is a URL shortener so that we URLs are easy to remember, easy to share verbally and it’s meaningful. The presenter was puzzled and said no.

I researched online and found an open sourced project called YOURLS, asked IT for 2 machines for me to prototyped the solution, launched it and demoed it to my team and emailed an internal list promoting the idea and get feedback.

The feedback was immediate but mostly negative
- Why do we need this, we have gotten along for now without it
- It’s insecure and can be used for phishing
- It’s useless and folks won’t click on it.
- Is this really your job?
There were a few folks who supported the idea because they used URL shorteners like http://bit.ly/ and said to give me a chance.

I continued to work on the project, demo’ing the http://GO/ URL shortener along with enhancements during our quarterly hack weeks. I started sending easy to remember URL’s to common thinks like go/food, go/wifi, go/printer, go/tony

Slowly the serviced gain traction and adoption, but very slowly. After about 2 years, I noticed there was some was drastic changes
- I see posters around the company promoting events and people had a GO link such as GO/printer or GO/security or GO/zoom
- I see in our chat rooms people sharing links such as GO/projectx or GO/help-whatever
- Because I talk about the GO links during new hire training, folks also were asked to create a GO/[your name] to their personal homepage
So what did I learn from this experience?
- For anything that is new and different, it will be a long and difficult journey.
- Being in a company that allows you to experiment is necessary for this type of work to succeed.
- If I truly believe a project is good for the company, I should just continue forward without asking for validation
Interview 1: Lyn Campbell, Corporate VP, Global Operations at Proofpoint

April 20th, 2018

I’m celebrating a milestone for a personal 10 year project and I’m seeking your time and attention.

Impactful Engineer shares the stories and journeys of women and men who are making significant impact in the software industry. The purpose of Impactful Engineer is to inspire young software engineers to see that are many paths they can take to move forward in their careers and grow their impact wherever they work

As I promise to my readers, I embargoed interviews until the first woman engineer interview is done.

The finished version is now published and I can’t wait to share it with my supporters and core audience (young engineers looking to grow and esp. women)

When you have 24 minutes to spare, please read the interview with Lyn Campbell who is a corporate VP, and she graduated an English major. I am looking for feedback on how I can make the site and interviews better.

Here is our first interview with Lyn Campbell, Corporate VP, Global Operations at Proofpoint

https://impactfulengineer.org/lyn-campbell/
A Good Engineer == A Lazy Engineer

April 28th, 2005
Software engineers are usually called upon to solve problems that involve large numbers.
1. large number of machines
2. large number of text to search
3. large number of page views
4. large number of users
In order to be an efficient software engineer, you must always keep in mind to be lazy. Ask yourself, what is the easiest way to design the system so that there will be minimal changes later on, how to design the system so that when the large number grows larger you and your team don’t have to grow as well. Always think what would happen when the large number is multiply by 10, multiply by 100, 1,000! If you can answer these question in your design process, then you know you’ve are on the right track.

Always think how I can be more lazy, how do I design the system so that others can help me scale the system 10x, 100x, 1000x.