I started this blog 3 years ago with the desire to use it as forcing function for staying relevant in the software industry. As I have been thinking through what it means to succeed in the software industry I've been writing those thoughts down and sharing my imperfect view of the industry with you.
Over the last 3 years I've published 152 posts and had the pleasure of having had 38,000+ readers (that I know of). To that end I feel like I've accomplished what I started out to do. This blog, for the most part, has focused less on opinion and more on learning. I've been able to cover topics such as fundamental data structures, mobile development, as well as leadership and career development.
While this blog has been a great source of joy for me, it's also been a time suck and source of stress making sure I have something ready to post Monday mornings. It's time to take a break. I don't know if it's permanent or temporary. But my goal is to just relax a bit and spend time with my family.
Thanks for reading.
Monday, October 3, 2016
Monday, September 26, 2016
Do you have the right mechanisms in place to course correct?
As humans, none of us is perfect. Even if we can, on occasion, execute perfectly on something more often than not we all need to course correct at some point. Some examples of when we need to course correct are:
- Having incorrect or invalidated assumptions
- Starting something that has a lot of ambiguity
- Finding out about missing or hidden dependencies
- Having a plan that falls short of delivering on a specific commitment.
- Failing to accomplish a goal, milestone or key deliverable
That list isn't exhaustive and is applicable to the projects we work on, the way we interact with our peers/directs/superiors, career development and many other aspects of our lives. Having mechanisms in place to help you correct your course *before* or soon after you get off track will help you be more successful. Here are some tips to help you setup mechanisms that enable course correction.
Be willing to change course
As humans change doesn't come easy for us. Once we set ourselves on a certain course we will naturally want to continue down that course because it's easy. This may sound obvious, but course correcting starts with being willing to change course.
What this means practically is that you have to be open to:
- Being wrong
- Doing more work
- Scraping work you've already done
- Having difficult conversations
- Asking difficult questions
- Being relentless about seeking the truth and proceeding with the *right* data
Ask questions that help you understand when course correction is needed
There are several questions that I try to consistently ask when checking in on the progress of something I'm working toward:
- Where am I on track?
- Where am I ahead of schedule?
- Where am I behind schedule?
- Is there anything I plan to work on that I no longer need to?
- Do I need to re-arrange priorities?
- Is what I'm working on right now the simplest/fastest/most efficient way to achieve my goal?
- What information do I have now that I didn't when I started? How does that change my approach?
- Is everything I depend on to be successful still on-track? If not, what does it take to get back on track?
- How does the recent decision about X affect me?
Meet regularly with your key stakeholders and solicit feedback
Making sure that you're on the right course means talking with your stakeholders often. Depending on the context of what you're trying to achieve, the form of these meeting may look different. But the key is that you're meeting regularly and getting as much feedback as you can.
Some common forms these meetings take are:
- One-on-ones: This is where you are meeting with an individual regularly and asking for specific perspective and feedback. These meetings are more intimate and can typically get into a lot of depth. These typically occur weekly or bi-weekly.
- Daily project sync up: Most agile teams do this in the form of a daily scrum. The purpose of this meeting is to make sure everyone is aware of hyper local changes. Talk about what was accomplished yesterday, what you plan to accomplish today, and what you may be blocked on.
- Program status meetings: This is where you meet with the key participants of a project or program and check in on the status. In this meeting you want to focus on things that are either off track or at risk of being off track. Most often I've seen this occur weekly or bi-weekly. It's really important to have people in this meeting who can authorize change.
- Stakeholder meetings: These are regular sync ups with the people that depend on you and your work or that you depend on. These meetings are typically with people that you don't have much visibility into day to day operations with.
- Team/Org meetings: This is time with your direct team. This time is best used for vision casting, transparency, and/or checking the temperature of the team (i.e. how are people feeling).
Monday, September 19, 2016
Development teams should be deploying and mainintaining production
Most of the software development shops I've worked at in my career didn't have developers deploy their own code. Typically the developers would create a release and hand it off to QA who would do some combination of manual, automated, and performance testing. When bugs or performance issues were found they'd send the release back upstream to developers who were already working on the next feature.
This creates a culture of fear that the production system needed to be protected from the developers. This is unhealthy in my opinion. Software development teams should be deploying their own software for four main reasons:
Software teams that deploy and maintain their own software in production tend to have a higher level of ownership. This is because they are involved in the full end-to-end software development life-cycle rather than just building the software. They become better aware of the machines (whether physical or virtual) that their software runs on. They're more likely to insist and push for deployment automation as developers tend to hate repetitive manual tasks.
When the developer isn't responsible for deploying their code they move on to the next problem space after they've "shipped" their code to operations. This typically means they've moved on both mentally and emotionally from that release. When a developer is responsible for pushing to production they're invested in the release getting all the way to customers. They become responsible for diving in and solving problems that pop up during deployment.
Accountability
When you're responsible for maintaining software in production, you're more likely to be accountable to what happens in production. Specifically, the dev team becomes more accountable to:
Insight
Understanding the health of your system means having the right metrics and validations in place. When software developers own deploying to production they're more likely to instrument their code well because they will need to validate that their deployments are successful. In my experience teams that deploy their own code better understand the performance characteristics and health of their systems. They are also better able to diagnose problems because they're familiar with the differences between their development and test environments and the production system.
Continuous Integration/Continuous Deployment
When a team owns their code end-to-end they are setup for success with respect to continuous integration and continuous deployment. They don't have to jump through hoops in getting their code into production and they can integrate deployment and test tools directly into their development pipeline. This encourages them to ship smaller features more often. By doing this, they decrease the time it takes to close the feedback loop and are better able to adapt to their customers ever changing needs.
This creates a culture of fear that the production system needed to be protected from the developers. This is unhealthy in my opinion. Software development teams should be deploying their own software for four main reasons:
- Ownership
- Accountability
- Insight
- Continuous Integration/Continuous Deployment
Software teams that deploy and maintain their own software in production tend to have a higher level of ownership. This is because they are involved in the full end-to-end software development life-cycle rather than just building the software. They become better aware of the machines (whether physical or virtual) that their software runs on. They're more likely to insist and push for deployment automation as developers tend to hate repetitive manual tasks.
When the developer isn't responsible for deploying their code they move on to the next problem space after they've "shipped" their code to operations. This typically means they've moved on both mentally and emotionally from that release. When a developer is responsible for pushing to production they're invested in the release getting all the way to customers. They become responsible for diving in and solving problems that pop up during deployment.
Accountability
When you're responsible for maintaining software in production, you're more likely to be accountable to what happens in production. Specifically, the dev team becomes more accountable to:
- Bugs
- Test coverage
- Deployment failures
- Poor performing code
When you work at scale there are often bugs that only show up in production. When developers deploy to production they become more accountable for fixing bugs, performance issues, and deployment failures as they are directly exposed to them during the release cycle. One thing I've seen successful organizations do is, when a release fails, block all further releases until the deployment succeeds. Developers that are accountable for these failures will be encouraged to fix them because they're prevented from moving on to the next new thing until the current thing is successfully deployed.
Understanding the health of your system means having the right metrics and validations in place. When software developers own deploying to production they're more likely to instrument their code well because they will need to validate that their deployments are successful. In my experience teams that deploy their own code better understand the performance characteristics and health of their systems. They are also better able to diagnose problems because they're familiar with the differences between their development and test environments and the production system.
Continuous Integration/Continuous Deployment
When a team owns their code end-to-end they are setup for success with respect to continuous integration and continuous deployment. They don't have to jump through hoops in getting their code into production and they can integrate deployment and test tools directly into their development pipeline. This encourages them to ship smaller features more often. By doing this, they decrease the time it takes to close the feedback loop and are better able to adapt to their customers ever changing needs.
Monday, September 12, 2016
Finding happiness at work.
Recently I was watching the film Hector and the Search for Happiness and it got me thinking about how work can either be a source of happiness or contribute to a sense of unease or unhappiness with your life. There are a few quotes from the movie which I think should be examined in the context of your job and your overall happiness.
Making comparisons can spoil your happiness
Even if you work at a company that stack ranks it's employees, you are not your peers. While looking to others and their accomplishments can be a great source of inspiration, comparing yourself to others can also be an easy road to unhappiness.
Instead of comparing yourself to specific people, who may or may not have the same gifts and talents as you, figure out what achieving and exceeding your goals in *your role* means. This means sitting down with your boss and having a conversation about the expectations of your role and what your goals are. I highly recommend creating SMART goals.
Work towards achieving *your* goals and not towards being better than your peers. If you consistently achieve or beat your expectations it won't matter if you're better than your peers. You'll feel valued and appreciated and likely will be rewarded for your effort.
Many people only see happiness in their future
Are you one of those people that only seems to be happy if you know you're on track to a promotion or a particular set of responsibilities or ownership? Having an aspirational goal is great, but if it's the only source of happiness at work it's getting in your way more than it's helping.
What is getting in your way of being happy right where you are? Make a list of the top five things in your current job that are getting in the way of your happiness. Then create a set of goals for each one to affect real change in your current role.
For example: let's say you have a co-worker who is driving you nuts. They're overly critical of your work and you feel like they're targeting you in an unfair manner. Set a goal to try to dig deeper into the tension and try to see your interactions from *their* side. Be blunt and honest and tell them you feel tension and would like to resolve it. You'd be surprised how much unhappiness in your current situation is resolvable simply by bringing it up.
Fear is an impediment to happiness
What fear is causing you to dread going into the office? Is that fear rooted in reality? The typical work related fear I experience is not feeling like I am on the same par as my peers. I'm afraid that I have to work harder than them to get the same thing or less accomplished. But at the end of the day this fear usually turns out to be baseless.
I've found that the best way to root out fear at work is to work closely with your manager and your stakeholders and define what success looks like. Your manager should be able to paint a picture of what success in your role looks like. Very likely, this will start with a job description or some internal HR document that describes the necessities of your role. Talk with your boss about that and ask for specific examples of meeting those expectations or exceeding them in your current projects. You should do the same with your project stakeholders. Make sure that what you're planning to deliver is what they're expecting you to deliver.
You're likely going to spend 2000+ hours a year at work. Why not make it a source of joy?
Making comparisons can spoil your happiness
Even if you work at a company that stack ranks it's employees, you are not your peers. While looking to others and their accomplishments can be a great source of inspiration, comparing yourself to others can also be an easy road to unhappiness.
Instead of comparing yourself to specific people, who may or may not have the same gifts and talents as you, figure out what achieving and exceeding your goals in *your role* means. This means sitting down with your boss and having a conversation about the expectations of your role and what your goals are. I highly recommend creating SMART goals.
Work towards achieving *your* goals and not towards being better than your peers. If you consistently achieve or beat your expectations it won't matter if you're better than your peers. You'll feel valued and appreciated and likely will be rewarded for your effort.
Many people only see happiness in their future
Are you one of those people that only seems to be happy if you know you're on track to a promotion or a particular set of responsibilities or ownership? Having an aspirational goal is great, but if it's the only source of happiness at work it's getting in your way more than it's helping.
What is getting in your way of being happy right where you are? Make a list of the top five things in your current job that are getting in the way of your happiness. Then create a set of goals for each one to affect real change in your current role.
For example: let's say you have a co-worker who is driving you nuts. They're overly critical of your work and you feel like they're targeting you in an unfair manner. Set a goal to try to dig deeper into the tension and try to see your interactions from *their* side. Be blunt and honest and tell them you feel tension and would like to resolve it. You'd be surprised how much unhappiness in your current situation is resolvable simply by bringing it up.
Fear is an impediment to happiness
What fear is causing you to dread going into the office? Is that fear rooted in reality? The typical work related fear I experience is not feeling like I am on the same par as my peers. I'm afraid that I have to work harder than them to get the same thing or less accomplished. But at the end of the day this fear usually turns out to be baseless.
I've found that the best way to root out fear at work is to work closely with your manager and your stakeholders and define what success looks like. Your manager should be able to paint a picture of what success in your role looks like. Very likely, this will start with a job description or some internal HR document that describes the necessities of your role. Talk with your boss about that and ask for specific examples of meeting those expectations or exceeding them in your current projects. You should do the same with your project stakeholders. Make sure that what you're planning to deliver is what they're expecting you to deliver.
You're likely going to spend 2000+ hours a year at work. Why not make it a source of joy?
Monday, September 5, 2016
Communicating Effectively In Writing
We use writing in all aspects of our lives whether it's an email, a text message, a blog or something else entirely. Writing is one of the most powerful mediums we have in communicating our ideas. Given that, it's important for you to understand how to communicate effectively.
Understand what you are trying to achieve
Before you communicate in writing you should clearly understand what you are trying to achieve. Are you trying to disseminate information? Are you making a call to action? Are you soliciting information? Understanding this will help you better frame your narrative such that you can effectively achieve your goals.
Lead with the call to action
Put the most important information first and layer in the context
Read it out loud
Proof reading silently make it very easy for your mind to skip over something that you've spent a good amount of time on. Proof reading out loud allows you to find areas where the narrative doesn't flow. It also gives you the opportunity to figure out where you have too much or too little information.
Understand what you are trying to achieve
Before you communicate in writing you should clearly understand what you are trying to achieve. Are you trying to disseminate information? Are you making a call to action? Are you soliciting information? Understanding this will help you better frame your narrative such that you can effectively achieve your goals.
Lead with the call to action
This is akin to putting the most important information first. Your reader shouldn't have to hunt for what you're asking them to do. You should be explicit up front about *what* the call to action is and then provide more information as to *why* you're calling them to act.
For example: "Project X is 8 dev weeks behind schedule and needs 2 additional developers for 4 weeks to meet the original delivery date."
Put the most important information first and layer in the context
Someone familiar with the problem space should be able to stop reading after the first few paragraphs or the first page and grasp the main point of the text. Your reader should only have to dig into the back story if they want. Providing too much context can get in the way of what you're trying to achieve. On the flip side, not providing enough context can leave your reader with more questions than when they started. If you layer in the context you give your reader the ability to choose if they have enough information or if they need to keep reading.
Footnotes: Writing is a unique medium that allows you to point out where your data comes from in such a way as to not distract from the main point. Footnotes give you the opportunity to back up your narrative with facts, but allow you to layer them in such that the reader only has to read what they care about.
Appendices: If you have a lot of context that is important but not primary to the narrative, throw them in an appendix. The curious or skeptical reader can go and dig more into the *why* of your narrative without you having to detract from the flow.
Proof reading silently make it very easy for your mind to skip over something that you've spent a good amount of time on. Proof reading out loud allows you to find areas where the narrative doesn't flow. It also gives you the opportunity to figure out where you have too much or too little information.
Monday, August 29, 2016
Why you should learn multiple programming languages and platforms
In the first decade of my career I wrote software in C++, Java, C#.Net, Ruby, Python, Objective-C, VB 6 and VB.NET. Additionally I developed for ASP, ASP.Net, and PHP based Web Sites as well as scripted in Powershell and Bash. Learning multiple programming languages was very helpful for me during my career as a software engineer.
Here are some reasons that you should learn multiple programming languages.
Trains you to separate the engineering from the language
Learning multiple languages teaches you to explore design patterns and engineering best practices that aren't platform or language specific. Being a great software engineer is about being able to identify the correct algorithms to solve your problem and being able to implement that algorithm in the language and platform that best solves the problem. Great engineers are able to build simple software and use design patterns that are language agnostic.
Once you've started to learn to identify design patterns learning a new language becomes less steep of a learning curve. Learning a new language is about learning the plumbing of the language, i.e the syntax, the libraries, and the run-time. Knowing what you *should* be building allows you to learn *how* to build it.
Exposure to different tool-sets and platform features
As you learn new languages and platforms you'll also be exposed to new tool-sets for building, debugging and testing your software. Using these different tools will help you to learn different aspects of interfacing with hardware and other software as the languages and platforms will likely have different layers of abstraction for different things. For example with C++ you'll learn better memory management. Whereas with Ruby on Rails you'll learn dependency management with tools like Bundler.
Become better at picking the right tool for the job
Learning the ins and outs of different languages and platforms will help you learn to pick the right tool for the job. You'll understand what languages excel at what types of problems. For example, you may need to write a script to parse files and find that perl's built in regular expression capabilities help you to write an efficient and simple script. You may want to build a cross platform game and decide that using C++ will help you port your game to multiple platforms without as much code duplication.
Monday, August 22, 2016
Creating work life balance
In almost every industry, but especially in the software industry, there's always enough to do that you could work 24/7. But that's not healthy for you or for your company. Not having a healthy work/life balance contributes to burn out, discontent with your employer/boss/team, and often general depression. Obtaining work/life balance is not like capturing a unicorn. It's not a myth. It just looks different depending on what your priorities are.
Different phases in life require different types of work/life balance in order to obtain satisfaction in life, achieve your career goals and prevent you from burn out. For example, when you're single and kid free a lot of your satisfaction in life comes from your day job. You'll want to invest longer hours because you'll be rewarded in both your life satisfaction and in your career growth. Contrast that with someone who is married and has kids. More of their life satisfaction will come from outside of work than from inside. They'll be trying to do a good job with their spouse, their kids, and their jobs.
Here are some tips that have helped me achieve a good work/life balance.
1. Set The Correct Expectations With Your Management Chain and Your Peers
You want your boss and your team to know they can count on you. But that doesn't mean that you have to be available 24/7. Have a conversation with your boss and let them know explicitly what to expect your in office and out of office hours to be. Understand that this is a two-way conversation and your understanding may be incorrect. Having this conversation will make sure that both you and your boss are on the same page.
For example: my son goes to sleep around 7 pm each night during the school year because he has to get up at 5 am. It's important for me to get an hour with him at night before he goes to bed since I don't see him in the morning. So, I sat down with my boss let him know that my goal was to try to leave the office each day between 5 pm and 5:30 pm each day because it takes me 30-40 minutes to commute home. We talked through this expectation and my plan to be in by 8 am each day. I also let him know that I am flexible and can occasionally stay later if the need arises, but that I it has to be the exception to the rule.
Knowing my goal helps me coordinate better with my boss. He knows that if something comes up after 5 pm that I will likely address it the next morning. He also knows that if something exceptional comes up that is important that he can count on me to address it.
2. Be Willing To Jump In As The Exception To The Rule
Most high tech companies have core business hours but the internet doesn't stop because it's 5 pm. Working in an industry which doesn't have an open and a close means you'll need to be flexible in your schedule and occasionally work before or after your normal day begins or ends. If you're working on a project with a tight deadline you're going to need to be flexible and willing to put in additional hours in order to maintain a good work/life balance as the standard rule.
3. Understand The Trade Offs and Be Willing To Accept Them
Different industries require a different level of commitment. For example, retail organizations are likely going to require you to work on or around the holidays. Why? Because that's when some of their core business during the year takes place. It's not reasonable to take a job in retail and expect to take Black Friday, Cyber Monday, or Christmas week off.
That's just one example. Each industry will have different trade-offs. Some will require travel. Some will require work on the weekends. Some will require long hours for a couple weeks out of the year during planning periods or before big products ship.
If you understand the trade-offs of your industry then it won't feel like your work is constantly encroaching on your work/life balance. It'll be a conscious choice you've made where you've deemed the rewards to be greater than the demand. You and your employer will have the same understanding of where the balance between work and life is and what reasonable and unreasonable expectations are.
4. Remove Work Email From Your Phone
This one has helped me significantly. At first I didn't have a choice as my work stopped allowing Android phones to connect to our email servers due to the Stage Fright vulnerability. The first few months I went through withdrawal and was afraid that I was going to drop the ball on something. But as I learned to set expectations with my boss and my peers I slowly started feeling more comfortable being disconnected.
In my case, I've explained to my management chain that I don't have access to email on my phone and didn't plan on VPN'ing in to check it while at home. But I also told them explicitly that if something came up to please feel free to text me. This gives them confidence that I'm not going to just fall off the face of the planet when I leave the office and it helps me to feel okay not being connected 24/7 to my job.
5. Exceed Expectations When You Are At Work
If you exceed expectations while you're at work then you'll build the trust that you need for your boss and peers to understand you will get the job done. Your boss and your peers will believe they can count on you to get the job done and won't feel like they need to micro-manage how or when you do the job.
Exceeding expectations assumes that you know what the expectations of you are. You *must* sit down with your management chain and have this conversation. You *should* have goals that are clearly defined. You *should* also talk to them about how to escalate to you on off hours. For example, if there's an expectation that sending you an email is enough to engage you after hours but you don't check your email after hours, then you're not going to be able to exceed expectations.
Here are some tips that have helped me achieve a good work/life balance.
1. Set The Correct Expectations With Your Management Chain and Your Peers
You want your boss and your team to know they can count on you. But that doesn't mean that you have to be available 24/7. Have a conversation with your boss and let them know explicitly what to expect your in office and out of office hours to be. Understand that this is a two-way conversation and your understanding may be incorrect. Having this conversation will make sure that both you and your boss are on the same page.
For example: my son goes to sleep around 7 pm each night during the school year because he has to get up at 5 am. It's important for me to get an hour with him at night before he goes to bed since I don't see him in the morning. So, I sat down with my boss let him know that my goal was to try to leave the office each day between 5 pm and 5:30 pm each day because it takes me 30-40 minutes to commute home. We talked through this expectation and my plan to be in by 8 am each day. I also let him know that I am flexible and can occasionally stay later if the need arises, but that I it has to be the exception to the rule.
Knowing my goal helps me coordinate better with my boss. He knows that if something comes up after 5 pm that I will likely address it the next morning. He also knows that if something exceptional comes up that is important that he can count on me to address it.
Most high tech companies have core business hours but the internet doesn't stop because it's 5 pm. Working in an industry which doesn't have an open and a close means you'll need to be flexible in your schedule and occasionally work before or after your normal day begins or ends. If you're working on a project with a tight deadline you're going to need to be flexible and willing to put in additional hours in order to maintain a good work/life balance as the standard rule.
3. Understand The Trade Offs and Be Willing To Accept Them
Different industries require a different level of commitment. For example, retail organizations are likely going to require you to work on or around the holidays. Why? Because that's when some of their core business during the year takes place. It's not reasonable to take a job in retail and expect to take Black Friday, Cyber Monday, or Christmas week off.
That's just one example. Each industry will have different trade-offs. Some will require travel. Some will require work on the weekends. Some will require long hours for a couple weeks out of the year during planning periods or before big products ship.
If you understand the trade-offs of your industry then it won't feel like your work is constantly encroaching on your work/life balance. It'll be a conscious choice you've made where you've deemed the rewards to be greater than the demand. You and your employer will have the same understanding of where the balance between work and life is and what reasonable and unreasonable expectations are.
4. Remove Work Email From Your Phone
In my case, I've explained to my management chain that I don't have access to email on my phone and didn't plan on VPN'ing in to check it while at home. But I also told them explicitly that if something came up to please feel free to text me. This gives them confidence that I'm not going to just fall off the face of the planet when I leave the office and it helps me to feel okay not being connected 24/7 to my job.
5. Exceed Expectations When You Are At Work
If you exceed expectations while you're at work then you'll build the trust that you need for your boss and peers to understand you will get the job done. Your boss and your peers will believe they can count on you to get the job done and won't feel like they need to micro-manage how or when you do the job.
Exceeding expectations assumes that you know what the expectations of you are. You *must* sit down with your management chain and have this conversation. You *should* have goals that are clearly defined. You *should* also talk to them about how to escalate to you on off hours. For example, if there's an expectation that sending you an email is enough to engage you after hours but you don't check your email after hours, then you're not going to be able to exceed expectations.
Subscribe to:
Posts (Atom)