How do you assess the value of an individual job?
How do you assess the value of an individual employee?
What makes you valuable to the job market?
What makes you valuable to a specific company?
How does value correlate to salary? Or does it?
Continue reading The 3 components of value for an IT/Software Development employee
So your business has a software system or software project that needs some attention.
Maybe there is pressure or need to replace the software system altogether.
The reasons for replacement or update can be varied. Maybe it’s scalability, security, usability, or features. It could even be due to maintenance issues or a business need to change the architecture.
Whatever the reasons behind it, you have a decision to make about how to move a software system to a better place.
How do you decide what level of investment / work to do?
Refactoring is a way to make incremental changes or add iterative improvements to a body of software over time without replacing what you have.
Refactoring software is like repairing a boat as you sail across the lake. You make small changes so as to keep the boat afloat and not sink it.
By refactoring you keep the usage, benefits and revenue of the existing system but iteratively improve what you have. In most cases, it’s lower risk and can be less disruptive and lower cost.
An adroit team of developers can identify and iteratively improve an existing system surprisingly quickly. This mechanism can breathe new life into existing code in less time, with lower risk and a far more predictable schedule that the full replacement options listed below.
Depending on the level of need and the root issues this may be a viable option. However, you the situation warrants it, you may have to replace.
At one large company I was at years ago, our VP was known for responding to requests for software development resources for new projects with the following paraphrased response: “First we steal, then we buy, then we build”.
By his response, he was showing the truism regarding internal software development economics.
Reuse is cheaper than buying.
Buying is usually cheaper than building and maintaining.
If for business or functional or support reasons you have to completely replace what you have, there are essentially three options.
This is a metaphor for reusing software from another project or system within your company. It’s also called creative re-use.
If you have multiple projects or programs, one may have the software foundations already in place for what you need. Reusing or repurposing that can take less total effort and risk than standard replacement methods.
At this time in software development history, there are commercial options for almost every business need. It is worth it to look at your requirements and scan the existing universe of commercial software to see if there is an existing fit. This method can reduce time to market or reduce time to reap the benefits of having the system.
Nothing exists that you can use for the need you have. Or maybe what exists so prohibitively expensive or not a fit for your needs. If you don’t have anything laying around to reuse and you can’t use what is available on the 3rd party market, you must build it.
If you have to build it there are a lot of considerations to make.
If you decide to build the software internally also consider the ongoing maintenance costs after initial release that will be associated with hosting, updates, training, security patches, environment, and feature improvements.
By considering all the available options a business has regarding software replacement, including re-factoring, an owner or sponsor improves the odds of the best decision for the company.
So you as a software developer didn’t have any of the career-limiting habits from my previous post. Great! Congratulations! You’re totally good and on your way to career growth and unlimited success.
But wait, there’s more.
There are many other habits that can severely mitigate your career growth. So here are three more.
So you have completed a feature and think it’s good to go. Your code is committed. You are feeling good about meeting your deadline. The QA folks are unleashed.
Then it happens. Thirty minutes later a problem is found. Oops.
Many times, I have had developers come into my office, proclaiming that a feature or bug fix was completed, tested and ready do go. Then, when external validation started, something was found within just a few minutes.
Granted we all miss things on occasion. But, if this situation happens too many times in your code, you might be forming the habit of lack of thorough testing.
There are many reasons this occurs. Everything from time pressure to just plain laziness can contribute to this. Sometimes it’s a lack of environmental understanding or unclear requirements. Regardless of the origin, this habit will severely curtail future career opportunities.
You can overcome this by using TDD, BDD or similar methodologies where appropriate. Thinking “testing first” can help you identify and code for those issues up front. Even if your organization doesn’t make formal use of test-driven development methodologies, you should still spend some time thinking through all the ways your code could fail and make sure you handle or document each one. Making that a habit will reduce the chance of an embarrassing situation with your boss or QA just minutes after you pronounce something done.
For an application that is larger than one person can manage, there is a natural migration to particular areas of expertise by the team members. Alice knows the database interface, Bob knows the CSS and front end, Sarah knows the business logic, Arun knows the device drivers and so on.
We all build silos of information and expertise. This is good and helps us provide value to the organization.
The career limiting aspect occurs when we withhold knowledge (either implicitly or explicitly) that could help other team members. The lack of free flow of information across developers reduces productivity, increases the odds that defects are found late and reduces overall department effectiveness.
If you become known as the person who “knew that last week” but didn’t bother to share with the team, you will become a pariah. The team members who could have benefited from that information will grow to resent you and begin to exclude you, exacerbating the problem of team effectiveness.
It’s a good habit to err on the side of too much communication as opposed to not enough. In the end, you will make the team more productive and be seen as a better team player and better example. It’s a karma-enhancing habit if you believe in karma. 🙂
Software tools and technology move at a rapid pace. The hot technical tools and trends of a few years ago become the archeological artifacts of tomorrow.
Back in my high school days, I was pretty good at BASIC.
Guess what. Nobody cares.
If I still relied exclusively on my ability to do BASIC for employment, if I had made it my ‘one trick’, I would have starved long ago.
I moved on to other more mainstream technologies over time such as FORTRAN, C, Perl, Python, PHP and the like.
If you, as a developer, acquire the reputation of being able to only do one thing, it will, over time, severely limit your opportunities.
Think about how technology has changed in just the last 10 years, then extrapolate that out over the next 20 or 30 years. We all better be embracing change. In the future, the most important skill could be the ability to learn new things.
Over a 40 or 50 year, career time span it is imperative to stay relevant. The saying goes “Adapt or Die”.
If you become a ‘one trick pony’ you will be limited in the opportunities that are available to you.
Hopefully, none of these describe you. However, if you have any of these tendencies, now is the time to change your habits so you can reap the future benefits.
Are you a software developer? Has your career flat-lined? Are you relegated to the back of the pack when it comes to assignments? Are you picked last when it comes to new projects? Have other developers stopped coming by and asking your advice? Has your manager stopped concurring with you for future work planning?
If you answered any of those questions with ‘yes’, then read on.
You may have developed some career-limiting habits without knowing about it.
Estimating effort in a software project is problematic at best and complete fantasy at worst. Some methodologies try to mitigate this, such as agile. But there are still times when a critical fix or change has to be delivered in a bound timeframe. In that case, when the manager needs an estimate, that estimate also encapsulates an implied promise, even though it is called an ‘estimate’.
As developers mature in their craft and environment, the accuracy of estimates generally improves. However, some developers habitually underestimate how long it will take them to implement a given fix or change.
I have worked with team members who, when asked how long a particular ticket would take to resolve, would say with certainty that it could be done in 4 hours. Then, 2 days, later I am in their office asking why that 4-hour change is still not complete.
When you, as a developer (or as a manager for that matter), miss the estimation mark regularly, you are falling into the habit of “over promising – under delivering”. It could be that you simply ‘shoot from the hip’ and make estimates without really considering needs to be done. It could also be that habitually bad estimates are a sign you have a fundamental lack of understanding about the project, tools or environment. Either case is bad and will erode your credibility and the perception your team members have of you.
If you struggle with small change estimate accuracy, start doing some light weight tracking in a notebook or spreadsheet (if you don’t have a tool that does it for you) for those types of estimates. Use the data you collect to give you better insight as to how accurate you really are. Once you have a few data points, you can start comparing estimated to actual delivery time. Try to answer the “why did I think it would only take that long” questions. Then use what you discover to adjust your future estimates.
Experienced developers have standard ways of architecting and implementing software. This shows itself in the way they organize code, name elements, test or use language idiom among other things. These are all good and are what make an experienced developer deliver quickly with higher quality in most cases.
I have seen cases in my experience where a ‘my way or the highway’ developer will go into an existing code body and completely violate the architecture and coding standards to implement a feature because it’s not their way.
The career limiting aspect comes in when that developer will ONLY do projects that way. Developers like this only function well in their little worlds. Since most companies have projects that need to be maintained (that you didn’t write), you will always end up writing code outside of ‘your way’. This behavior frustrates the team, confuses future maintainers, creates contention and generally adds to the chaos with little to no actual benefit to the project itself.
The modern software development environment has a wide array of excellent tools to make work go faster, and at higher quality. The capabilities of today’s IDE’s (integrated development environment), compilers, languages, editors, debuggers, frameworks and DEVOPS tools are must have for any professional developer.
Tools are a necessary force multiplier in our industry. Mastery of a tool set for your environment is prudent and a productivity enhancer. I once had a developer on my team who was an Emacs wizard. It was a real show to watch him edit and refactor code with Emacs because he was so adroit with its interface and shortcuts. However, when you have that level of mastery you tend to want to use that tool for everything. You have heard that old saying: “When all you have is a hammer, everything looks like a nail”.
The problem is when we get so used to one thing and stick with it to the detriment of learning new ways and methods. When we stick with only one tool, regardless of the circumstance, we artificially limit our ability to solve problems with more advanced or idiomatic ways with other tools. And that is the career limiting aspect of tool worship. The software tools at our disposal today are evolving at a rapid pace. And by sticking with the tools you are comfortable with you forgo the personal career growth that comes with learning new tools and the commensurate skills.
Would you trust a car mechanic who tried to solve every car repair with just a wrench or just a screwdriver? Of course not. There are many repairs that need way different tools. Neither should you be a developer that only has mastery of one tool.
A little introspection on a regular basis, and some heart to heart discussions with those who know you best, can illuminate these or other career-limiting habits you have picked up. Knowledge is the first step towards change and improvement.
One of Marc Andreessen’s most quoted statements is “Software is eating the world“.
All that software has to be written by someone (or something in the case of code generation).
There are a lot of software developers and they come in a wide variety of skill levels. The question as a business owner or software development manager is how do you find developers that are 10x better than average? After all, no one wants to pay a beginner developer to learn their craft. The 10x developers are those that can move a project or, in some cases, a whole business forward. They are able to far outproduce average colleagues in both quality and quantity of results. And, for the enterprise that hires them, they are a far better value. To borrow a phrase from the old TV show Kung Fu, they are able to walk on rice paper.
So what are some characteristics and habits of 10x developers?
Here are 12 that stand out to me.
Working closely with the customer is an essential help in avoiding building exactly the wrong thing (and thereby having to re-write it). The 10x developers I have worked with are effective at keeping the customer in the loop of development (even before agile) to make sure that what they implement will meet the customer needs without significant re-work.
Whether your environment is enterprise Java, embedded systems in C with a custom RTOS, web delivered apps with a PHP or Ruby framework or some .NET application there is an eco-system to consider. That eco-system is the sum total of the environment that your application is built and operates in. For example, when writing real-time embedded software, you had to master the compiler/linker tool chain, the RTOS environment and the specific hardware and sensors that you were working on. The 10x developer understands the pieces of the eco-system, how they work, how they fit together and how they impact the code.
The 10x developer is a fluent speaker of their language of choice. Bruce Eckel has written a couple of books where the titles begin with the phrase “Thinking in”, like Thinking in C++ or Thinking in Java. That is literally what 10x developers do. They have the bulk of the core language memorized. When they sit down to code, that language flows out of them like water from a mountain spring. Native language speakers can be more expressive and idiomatic in their implementations. They know the right built-in function. They know whether it is …(needle,haystack) or the other way around. They look at the language manual when they need to but that is not often. And, for languages that continue to evolve, like Go, PHP or Swift for example, they keep up with the changes.
The 10x developer writes code that is clear, modular and straightforward to extend. They document consistently. They communicate intent with their classes, methods and variable names. There is little ambiguity in what a method or class member does. They produce code that is usually fairly intuitive. When you open the files produced by one of these folks you can say a professional has been here.
One of the most time-consuming activities of a developer is trying to figure out what went wrong when code execution fails but does so with no trace, clues, breadcrumbs, log entries, exception stacks or the like. A 10x developer will leverage language features, like exceptions and logging libraries that allow them to communicate what errors occurred and their context. This leads to quicker resolution of problems.
One 10x developer that worked on my team showed up on their first day with a hard drive full of their personal code of libraries and utilities they had written. That fact allowed them to move very fast. No re-inventing the wheel. No figuring out how to re-write some basic algorithm or library. They brought tools with them.
Maybe you are ‘vi‘ person, or emacs. Or, you could be a NetBeans, Eclipse, or Visual Studio user. You might be a PHPStorm or PHPed expert. How about Sublime Text or edlin (just kidding)? Notepad++ anyone? Or any of the other hundreds of other great tools. Regardless of their tools of choice, a 10x developer has a toolset they like, have mastered, have customized and that allows them to turbo charge their output. On one team I led, I had a developer that was an emacs guy. He could make emacs slice, dice, julienne and dance on a pin. It was fascinating to watch him code and edit with emacs because he was so fast with it. That mastery gave him a significant advantage over those who were just average with the tools.
I know, some of you are thinking, 10x developers don’t need no stinking frameworks. Yeah, well, maybe. Modern frameworks provide so much functionality and give developers so much leverage in speed of creation of complex apps that they cannot be ignored, especially if you care about time to market. 10x developers with mastery of say Ruby on Rails, or Django or Laravel can produce web applications with remarkable speed. Fully functional, complex web apps. The extensive API’s of Java or .NET provide astounding capability that a 10x developer can leverage to further accelerate development speed and leave their parochial, framework-less teammates in the dust.
Every language has its way of doing things. In the Python community you see mention of doing things ‘pythonic‘ which is a reference to doing things in a native python language way. When I first started writing python, I came from a C background. It was amazing how much like C my python looked. But that was not idiomatic python. I had to learn to use the constructs of the language and the libraries natively, the way they were meant to be used. By doing that, I would take what was 20 or 30 lines of code and make it 5 or 6. 10x developers do exactly that with their language of choice. And it accelerates their results.
Any code written will eventually have to be executed. It will take up memory, use system resources and impact other programs in shared environments. 10x developers write code with these secondary effects in mind. How long a transaction should take, how much extra memory an algorithm extension will use or what additional cpu will be taken if we increase the message throughput are sample considerations in this area. A 10x developer will gain insight through testing and experiments that will build intuition for future projects. They code so as to eliminate as many secondary effect surprises as possible.
You can spot the code of an amateur easily. Repetition. You see a lot of cut and paste evidence throughout the code body. When noobies need to do the same operation they cut and paste the few lines of code needed instead of stopping to make a method or function to do the job. This practice adds bloat, decreases maintainability and reduces readability in many cases. 10x developers modularize their code and have effective class structures so they don’t repeat themselves.
Software configuration management tools are the backbone of any successful longer term development effort. Tools such as Clearcase, GitHub, SVN, or Perforce are essential to tracking, releasing and maintaining any software project. Features such as tagging, branching, merging, and finding the accurate delta between two releases are crucial to a high quality developer and nonnegotiable for a quality software team. A sure sign of a beginner is keeping code in their home directory or desktop and making a new file or folder copy each time they make changes. A 10x developer understands the SCM tools they use and leverages them to precisely know what they did, when they did it, what it affected and where it went, very quickly.
Certainly these habits alone won’t make you a 10x developer. However, they will take you a long way down the path. If you incorporate these habits and characteristics in your coding practices you too may one day walk on rice paper.
