Today I want to talk about something that developers don’t talk about too much. We talk a lot about technical skills – the latest frameworks, algorithms, test strategies, architecture, etc. – but not a lot about the soft skills. I want to talk about the mindset I have and believe good developers should have. Not just for automation, but for doing big, audacious things that impact lots of people.
This post is related to something I heard from the Software Engineering Daily podcast that I listen to during my commute. In listening to one of the podcasts, Jeff mentioned something about Google employees not meeting 100% of their goals. Instead, they should meet 60-70% of their goals. Less than that probably means the goals weren’t realistic, but more than that may mean you aren’t thinking big enough. You can read more about that Google policy here.
I should also note that this blog post is my opinion. Not everyone may feel the same way as I do about this topic. But I’ll explain my reasoning as we go. There isn’t really a ‘perfect’ employee; this is just my opinion of what a good employee does.
Generally when you first start at a new company, you need a few weeks/months to get up to speed on how the business works.
- What is expected of me?
- How does the day-to-day go?
- What is the development lifecycle?
- How do code deliveries work?
There are several that stay at this level. They learn how the daily operations go, and they conform to this. To some extent, this is good. This type of employee can get their job done and add value to the bottom line.
After a while, however, this type of person will get into a rut. Every day is the same. You’re not learning anything new, and there are still problems that exist within the company, but lots of people are ‘resigned’ to a specific way of thinking.
- “It’s always been this way.”
- “Well, there’s just nothing we can do about it.”
- “I’ll just do my job and not worry about it.”
Then there are the people that dream big. That come up with big, hairy goals that seem impossible. Rather than just look a few feet ahead, they look miles down the road to where they can be in the future. These goals don’t just get work done, but they have the potential to double, triple, or even 10x everybody’s productivity when they are done.
As an example, consider using continuous integration with unit tests for a team that does almost 100% debugging. Over time… say over months or a year or two, a well-written set of unit tests could prevent bugs from cropping up over and over. Over time, rather than spend, let’s say 2% of their time developing new features, that team could spend 50% or 75% of their time on new features. This improvement was because they don’t have to spend so much time debugging or supporting old code, because it now has much higher quality.
That’s just one example. But when big goals like these are presented, they seem ridiculous. There’s no way anyone will ever have time for it! But similar to Google’s idea that you don’t meet 100% of your goals (because you aren’t thinking big enough), even getting 50% of the way done on a huge goal might be a very big improvement.
Sometimes it seems there is no way you can have an impact on a situation. Keep thinking big and working towards a solution! Discuss ideas with management or with co-workers. Make time (not I didn’t say use your spare time) to try small things to see if they make a difference. It takes a mindset change. Rather than accept some situation, take ownership of any part that you can make better.
A part of this also means you take on risks. These should be smart risks, but they often have a good potential to fail. This is because you are learning a lot in the process. While too many risks is bad, never taking any risk means you aren’t growing as an individual or as a company. In short, your competitors will eat you alive.
It’s these types of ideas that can rock entire industries… or on a much smaller scale, make yourself or your team much more productive.
Break It Down
We can’t leave these huge ideas as pie-in-the-sky things. We have to break down these huge, risky ideas into more manageable chunks. We need to try to find value in smaller subtasks from this huge task.
In the example I gave of continuous integration and unit testing, a first step may be to write one unit test against existing code. That task alone has several subtasks:
- Choose a unit testing framework (PyUnit/JUnit, for example)
- Learn just enough to write and run simple unit test
- Morph that simple unit test to run something against your code rather than some example code you found online
One you have one unit test, you have some paths you can take. Perhaps you want everyone to be notified when that unit test fails?
- Find a server (if this is too much, just use your laptop with a publicly available IP to start)
- Install a continuous integration server software (such as Jenkins) on that server
- Set it up so it can send emails
- Make it get the source and unit test code and run it when a commit occurs
If any of those above steps are too big, you can once again break them out into smaller and smaller steps.
Breaking up work into smaller chunks of work is a skill in and of itself. It’s really good for breaking up huge goals into bite-sized chunks to make that dream a reality.
How to Come Up with Big Goals
Once I understand how the business works, I find problems that are annoying or take a long time. Then I attempt to find solutions to them. Some of these are a lot easier to solve…
- Problem: It takes a while to tag our software, and it’s inconsistent
- Solution: Create a Jenkins job that does it for us after filling in a few parameters
Note too that the solution will definitely vary based on what skill set you have and what technologies you are familiar with.
What if the problem is a lot harder?
- Problem: We don’t have hardware in time to develop our software.
- Solution: hmmm….
In these cases, doing some research can prove useful. Having experience with those problems from other companies and being part of the solution can also help. In the case of no hardware, I know from experience and research that the following can help:
- Unit testing
- Emulate hardware
- With Docker containers
- With QEmu
- Use hardware that’s very similar to the real hardware
- Create an well-defined abstraction layer so you can write all the code surrounding that hardware and test it without having the hardware. Once hardware arrives, implement that abstraction.
In general, look for problems and research how others have solved the problem. I usually find an abundance of things I can work on once I’ve been at a company for a few months.
The best employees think big. They don’t accept the norm and give up. When problems arise, they may not be able to fix the problem immediately. However, a big goal can be formulated and broken down so that the problem can be solved over time.
Don’t give up! Keep working towards that goal. Even if you only hit 60-70% of it, you still may gain a whole lot. 60% of a working solution may reduce the pain of that problem by a great deal. There’s still a good business case for implementing that big goal.
This is how the best companies/employees get better. They identify problems, form big goals, and go after it!