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.
It was the first tech conference I had attended in years. And waiting this long to attend a technical conference was a mistake.
Last week I had the opportunity to attend the ITRoadmap conference put on in Fort Worth, Tx. by the fine folks at IDG.
I enjoyed a well-paced day of keynotes, panel sessions, vendor presentations and tutorials.
I had breakfast and lunch with very interesting groups of people and discussed relevant current issues and found out how they are dealing with them.
I even ran across 2 guys who live very near me that I had never met before.
I spent time discussing culture issues with one of the panelists on the “Best IT places to work” panel. He gave me some great ideas regarding culture and employee practices to improve engagement and retention.
I left the day refreshed, better informed and motivated.
So here are my 5 reasons you should attend a conference near you.
As an IT and software development director, it was enjoyable and informative to meet the same type of people who work in my geographical market and get to know them and their business.
I increased my network, made new friends and learned new things about some of our local businesses.
It was good to hear how those folks are dealing with some of the same problems I have to deal with. I walked away with new ideas.
The tutorial sessions and vendor presentations were well done and educational.
I learned something new in every session I attended.
I walked away with new techniques to try, new tools to investigate and new acquaintances to further my reach.
I made connections to people and businesses that will help me in the future as well.
I learned about some new tools from Dyn that can help us with product delivery to our customers.
I came away with new DevOps strategies from Irwin Lazar, Vice President of Nemertea Research.
Dean Shroll of Sophos gave an interesting and scary talk about ransomware and the current threat landscape.
And I met some folks who work very close to me that I can continue to develop friendships and learn from.
Here are just 3 small examples of the talks and tutorials that were given.
Derek Hulitzky provided a talk with 3 short case studies of companies that have made profound digital transformations their business.
Mikel Steadman, Director of Sales and Solutions Engineering at Dyn gave a fascinating talk regarding doing business on the internet and provided some perspective on the recent DDoS that Dyn suffered.
Nicole O. Fontayne, Vice President, Chief Information Officer for DART described how they deal with the enormous IT complexity of a metro area transit system.
We learned about the trends in hiring, retention, IoT and cloud migration and scaling, DevOps, Security and tons of others.
And yeah, you can also find folks who have businesses that need people like you. It can be a recruiting (or hiring) bonanza depending on what you are looking for.
It was so worth missing a day of work and the pains that come with that to attend the IT Roadmap conference. It was a great benefit to me and I will sign up as soon as registration starts next year.
So go and find a good conference near you and attend, and participate. You will be glad you did.
We all like to think what we do helps move our business and products forward.
But………
Sometimes subtle, embedded habits and tendencies we have actually increase the rate at which a business accumulates technical dead. Which of these does your business have?
You have been in those meetings.
You know the meeting, where the executive in charge slams their hand on the table to get everyone’s attention after an extended debate.
And then, with red face of anger and the decibel level of a 747 on takeoff, bellows “this product will ship on time“.
This display is usually accompanied by promises of some sort of employee retribution if the fantasy date is not met. It is at that point the meeting is really over and no one will dare raise any additional points no matter how real and urgent they are.
Using emotional outbursts to attempt to motivate a team doesn’t create technical debt per se. However, it is the short-sighted executive decision making that results in this environment will create technical debt.
There may be valid reasons why the product can ship on time. However, there may be serious issues, just under the surface, that could cause the company big problems if the ship date is met.
Astute executives ask penetrating questions, validate assumptions and create productive dialog. Click To TweetAstute executives ask penetrating questions, validate assumptions and force the analysis and discussion that create productive dialog. It is only in an environment where subordinates and colleagues feel safe in disagreeing or bringing bad news that all issues can be on the table and then dealt with appropriately. Otherwise, things that could be real issues get covered up, hidden, or ignored. And when issues and technical debt builds, are you can rest assured they will pop up later at the most inconvenient time.
Typically managers take short cuts that build in technical debt for two reasons: 1)because they are incompetent or 2)because they are trying to make points with the boss by finishing earlier, cheaper etc.
Incompetent managers yield all kinds of pernicious evil in software or IT implementations. They can hire the wrong employees, force inadequate or inappropriate implementations, misunderstand technical requirements, force the use of the wrong tools or rewarding the wrong behaviors. The results of these managers will always cost more, take longer, disappoint, and need large corrective actions.
The brownie points gang are those managers that always want to have the right answer.
“Yes we are on schedule”
“The project is coming in under budget”
“Yes we can add those all those new features”
“No, that change won’t affect our delivery capability”
Looking good is more important than reality and truth. These types of managers are skilled at making themselves look good and figuring out some other person, group or division to take the fall when things hit the fan.
Adroit managers work to always increase their competence through training, assignments, asking questions, checking assumptions and working closely with their teams. They understand that by continual growth and disciplined execution they will impress their bosses and it will be real.
I was recently working on some software and came across a whole section of code that had been copied identically and only a couple of lines changed to accommodate the different situation. This is a perfect example of developer laziness. Instead of taking the extra mental effort and time to create a method to do the work so that it was encapsulated in one place,
This is a perfect example of developer laziness.
Instead of taking the extra mental effort and time to create a method to do the work so that it was encapsulated in one place, technical debt was created by copying a bunch of code unnecessarily. It may have allowed the developer to quickly get work committed but built in a headache for someone else to deal with later.
Skilled developers understand when small refactoring can save huge time later. Click To TweetSkilled developers understand when small refactoring can save huge time later. They know when it is worth it to make additional small investments to avoid bigger problems later. Invest in resources to train developers on your systems, standard coding best practices, and effective coding refactoring processes.
What’s your team training plan look like?
Do you cross train?
Are you encouraging them to learn better methods of coding or testing or implementation?
Are you giving them tools to improve code, deployments, or testing?
Is continual learning part of your culture?
If you don’t have answers for these questions for your team or yourself then you could be inadvertently building technical debt in future implementation.
The technology software and IT is advancing at an ever increasing pace. Your organization has to adopt an adaptive, learning mindset to stay up with advancements. And incorporate them to give your business advantage.
Improving teams create and execute training plans for the tech they are involved with. They set expectations for learning, growing and utilizing what they learn to improve products, productivity, and performance.
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.
The late Stephen Covey, in his seminal book “7 habits of Highly effective people“, wrote that one of the 7 habits is: “Seek first to understand, then be understood”.
An effective way to “seek first to understand” and communicate with someone is to put yourself mentally “in their shoes”. This is the essence of the habit Stephen Covey introduced in his book.
In High School debate, participants prepare to argue both sides of a presented issue. This means a debater has to thoroughly research, understand and prepare cogent arguments for both the negative and affirmative sides of the issue. The debater has to put themselves in the shoes of both a supporter and detractor of the issue. The best debaters do this well.
This same metal exercise can also improve your next software application.
By changing mental viewpoints and analyzing the software project from the new point of view, you can become aware of new issues to solve or new opportunities and features. You can do this regardless of your role on the team.
This exercise helps prepare you for the client meeting, that big design review or the next sprint planning session. It can help you work more closely with the product owner and improve your design and plan.
If you are one of the general roles of a project team, forcing yourself to mentally assume the viewpoint of the other roles in the software project will improve communication, understanding, planning, and results.
Forcing yourself to assume the viewpoint of other roles in a software project improves results. Click To TweetHere are seven viewpoints you can use in your mental exercise:
The designer creates the look and feel, screen flow and color scheme and page layouts.
Designers are concerned with creating a compelling user experience in a style that complements the genre and use of the application. Style, simplicity, cognitive load, and utility are key concerns the designer has.
If you are not the designer, you can consider methods to express style, or improve the usability of the app. Realize there are many opinions that influence the aspects and implementations of design. Many times there is no one right answer. The designer has to arbitrate these, sometimes conflicting, opinions.
The developer is the person (or team) actually doing the coding of the application.
The coder has to worry about the execution environment, standards, tools, compatibility across consumption devices, security, language implementation, performance and 3rd party services, code libraries and API’s that will be used.
To put yourself in the shoes of the developer, consider the job of a translator, translating one language to another. There is a lot of work and knowledge that goes into translating a language. Nuances such as tense, idiom, gender and the like add complexity as well. That’s essentially what a developer does, translating the requirements and desires of the team into software, but also with a lot of other constraints. Many of the constraints coming from the environment and devices that have to run the app.
The project manager is responsible for schedule and resources.
Their big concerns are resource utilization, schedule, milestones, reporting, test results and barriers to completing the tasks. And, if the project manager doesn’t have direct reporting control of the resources, their job is much more difficult.
To envision their world, think about being the director of an elementary school orchestra. They attempt to get all the band members set up with their instruments and music, on key, and on tempo so that what the orchestra plays will actually resemble music.
This is the person who is funding the development. The business owner or VP who is sticking their neck out (and budget) to get the project done.
To think from the owner’s frame of reference, consider making a large purchase with your own money. Writing a big check out of your own account always gives you pause. It motivates you to thoroughly investigate the value of the purchase, the terms, guarantees and warranties and lifetime costs and service. You don’t write big checks out of your own account without sufficient reassurance that the purchase is a good one. Thinking about the owners situation in this manner helps you better evaluate the value proposition, return, and on-going or hidden costs. All of which are key concerns for the owner.
The people who actually pull out their credit card and pay for and use the app you are creating.
They will have lots of needs and questions. Why should they buy? How will they realize value? What will their pain points be? How will they consume the app?
All of these and may more questions will have to be answered in order to produce a product that is valuable and has utility for the customer.
Consider those companies with products already in or directly adjunct and selling to the market space you will be in.
What are the pain points of the customers of your competitors? What is the competitors unique value proposition versus that of the app you are building? Why would customers potentially buy from your competitor and not you?
Answering these questions will provide greater clarity about the market position, value proposition and relationship to existing competitor offerings.
The maintainer is the poor souls who come after the initial release to clean up after the parade and maintain the app and system that was created.
What documentation will they need? How can you structure the app code to improve maintainability?
The maintainer will be the person fixing bugs, adding features and making other needed additions and improvements. Making their life easier through well architected and written code, template based screen layouts, comments and a software spec will speed maintenance activities lowering long-term cost of ownership.
If you spend a little time, thinking about your project from the viewpoints of the various roles, you will be a better team member, facilitate better communication among the team and make the project go smoother and improve the results.
Work on assuming the viewpoint of others to more deeply think about your application, improve your results and reap the rewards. And, who knows, you might make it a habit.
Cue the Psycho music. Throw in a Wilhelm scream. Run for your lives!!! To some alpha developers, the mere thought of a software development manager coding is worse than 12 hours of fingernails on a chalkboard. And scarier than a night in the Bates Motel.
Yeah, I get that. But wait.
There are some valid, and practical reasons for a software development manager to also take a few story points in a sprint now and then. Here are five.
Today’s development languages, technologies, tools, and environments evolve with ever quickening pace.
The experience you had as a coder 10 years ago is aging faster than the milk left out on the counter last night.
Taking a few story points now and then forces to you learn and keep up with tech, staying relevant in your field and your own product and environment. It also allows you to communicate with better understanding and at a deeper level with your development team.
But doing a development turn now and then you keep fresh in your mind the nuances of your companies particular development environment. And the pain or bliss it causes your team.
This knowledge can also improve your on-boarding process and make you more relevant in discussions when it comes time to migrate to new elements in your environment.
By actually doing development on the products you manage, you will be far more knowledgable and effective in your communication to customers and superiors. You will understand the context of defects and issues that come up more thoroughly. You will be able to communicate with your team at a higher bandwidth during feature design or sprint planning.
Sometimes you will find yourself in a pinch.
Your key developer is out, camping in the remotest parts of the Colorado mountains and completely off the grid for 2 weeks. The other guys are slammed and a defect found in his code needs to be addressed and pushed to production in 2 days.
If you have been keeping your skills sharp and doing your turns, you can step in and cover this situation in most cases. I know I have.
If you can still take a ticket or two now and then, you will also silently earn greater respect from your team. They will believe you are in the foxhole with them. Your questions to them will be more on point and from an orientation of better understanding.
There is an influence from the professional management ranks that anyone with the requisite management training and skills can manage software development without the pre-requisite of coding experience. I have worked with PM’s who were good enough to pull that off. However, the PM’s who had actual development chops were far more effective in my experience.
So scare your team to death and sign up for a few story points in the next sprint. In the long run, I believe you will be a more effective software development manager for it.
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.
