In a nutshell
- Software is the main engine of revenue and growth for most companies. It is also done at a scale that makes it impossible to micromanage everything top-down.
- Thus, being just a code monkey won't cut it. Professional developers are expected to contribute to the company's overall success: provide a competitive advantage, fuel sustainable growth, ensure adaptability to changing market conditions.
- In this article, I'll take a deeper look at what makes companies successful and what skills you need as a developer to help achieve this success.
The evolution of software development (too critical to neglect, too complex to micromanage)
As Marc Andreessen famously said in 2011, software is eating the world.
Modern companies depend on software as never before. Even if they don't sell it directly as a product, software is still fundamental to driving their operations and growth. It's critical for their customers, employees, suppliers, and partners. It's the engine that runs the business - and the network that connects it with other businesses. It's the cornerstone of the company's success.
At the same time, the software got bigger. Much bigger. And the software development process got incomparably more complex: Huge teams. The whole portfolios of products. A vast network of interconnected APIs. Complex distributed architectures. Tens or even hundreds of external vendors. Constant progress at a crazy pace. Cutthroat competition and continuously changing user tastes. No manager, analyst, or architect is able to micromanage it all. The responsibility has to be distributed.
And this completely changes the game for us, developers.
Raising the bar for software developers (the new definition of a "code monkey")
A "code monkey" isn't a new term. Developers who just churn out code without looking at a broader context were frowned upon from the early days of programming. However, for a long time, this "broader context" just meant more conceptual work like code design or architecture. But it doesn't cut it anymore.
Nowadays, I'd define a code monkey differently: A code monkey is a developer who contributes only to building software, not to the holistic company's success.
Yes, this is why we, developers, are hired. To generate business value. To make companies grow and thrive. And this requires a different mindset and a different, broader set of skills.
But, first of all, you need to understand what makes companies successful - and where you fit into this puzzle.
The 4 key elements of the company's success (and how you can influence them as a dev)
The recipe for a company's success, while insanely hard to achieve, is, at its core, very simple.
First of all, a company needs to have a competitive advantage. It needs to be better than the competition (or at least differentiate itself enough) in one or more of these aspects: have a better product, be more innovative technologically, build new products faster, or be cheaper.
Then, when the company becomes successful, it naturally starts to grow. Rapid growth is hard to manage and - if the company is not skillful at it - can destroy its competitive advantage.
Next, to be truly successful, a company needs to sustain its competitive advantage over time. It needs to cut enough corners to win now - but not as many as to die the "death of a thousand cuts" later.
Finally, the world never stands still. To not lose its edge, a company needs to continuously evolve to adapt to the ever-changing user tastes, competition, and market.
Let's now take a look at these 4 ingredients in more detail.
Competitive advantage: Product
Building a better product is the most obvious competitive advantage. If users like and buy your product more than the other ones - you win. But what convinces them to do so?
It all boils down to two things: addressing users' needs and providing a great user experience.
So how you, as a developer, can influence these two areas?
- Improve your communication skills to collaborate effectively across functions, with designers, product managers, business stakeholders, and users. Especially, learn how to talk to non-programmers (explain technical concepts simply, abstain from jargon, be patient with less tech-savvy people, etc.).
- Learn the principles of experimentally discovering what users want: Agile, empiricism, iterative development, Lean Startup, product discovery.
- Get good at working in short iterations, building small MVPs (Minimal Viable Products), and rapid prototyping, to help product managers validate ideas faster.
- Understand how to rapidly test ideas without coding (fake door, Wizard of Oz, concierge, and similar techniques).
- Learn the fundamentals of the product metrics and get a good overview of various analytics approaches (page views tracking, event tracking, backend API requests tracking, heatmaps, etc.) and the analytics tooling ecosystem (Google Analytics, Pendo, Segment, HotJar, and so on).
- Don't push to always solve everything by writing new code. Get comfortable with solving problems through 3rd party integrations and no-code solutions.
- Learn the basics of usability and user experience (UX).
Competitive advantage: Technology
Developing more advanced technology is another competitive edge. This is a bit different from just creating a better product. Of course, you still need to solve real user problems, but your winning strategy is not making the product more fine-tuned and polished but making it capable of things no one else is capable of.
Imagine invoicing software. Making re-typing the content of paper invoices into the system by hand smoother, faster, and done in fewer steps is one thing but being able to import them automatically, without typing anything, through advanced text recognition and extraction would be at a completely different level, even if the interface is not that polished.
It doesn't have to happen at such a dramatic scale, though. Even small technical advancements can provide a competitive edge: make processes faster for the user, reduce their costs, make the product more capable.
But how a regular developer can help their company gain a technological advantage?
- Get a good overview of the existing ecosystem, both open source and commercial: languages, frameworks, libraries, cloud and SaaS platforms, APIs, tooling, and so on. Often the advanced capability you need is already out there, available as a 3rd party library or service - you just need to know it exists and understand how it can be used.
- Stay up to date with the newest trends and technological advancements (especially the upcoming, not yet widely adopted ones) to be able to notice and exploit opportunities to gain a technical advantage.
- Learn about your company's business domain, its product, and its competition, so you can propose the most innovative technical solutions to the business problem at hand.
- Stay up to date with what's happening also outside your company's domain. Track what other popular apps are doing - what's the current state of the art in the broader industry - and "steal" and adapt the best ideas to your company's needs.
- Experiment with new stuff regularly (just enough to get a good grasp of what it is about and be able to quickly learn more about it when needed).
- Get good at researching, quickly learning new tech when needed, and doing small prototypes and proofs-of-concept.
Competitive advantage: Process
The next way of gaining a competitive advantage is through better processes. In other words, the ability to build stuff faster than the competition without sacrificing quality. In the short term, it will give your company the first-to-market advantage. In the long term, it will allow you to experiment more rapidly, which will impact also the first two advantages: better product and technical innovation.
An important part of a good process is also the ability to continuously refine the process itself, to stay ahead of the competition in the long run.
Processes - especially related to efficient delivery - are something developers have a lot of influence over.
- Become a fast, efficient coder. Learn your IDE in-depth. Get good at debugging. Use tools that speed you up: auto-formatters, code generators, code intelligence, hot reloading, etc. Understand how to organize the codebase to navigate around faster.
- Learn how application architecture impacts not only scalability and performance but also efficient teamwork, code navigation, and debugging.
- Build a robust toolbox of techniques to minimize the number of bugs (and to fix them more efficiently): unit testing, error handling, application monitoring and logging.
- Understand technical debt and how to strike the right balance between cutting too many corners and over-engineering. Become good at making the right compromises between delivering business value and maintaining necessary non-functional features (reliability, performance, security, scalability, maintainability, quality).
- Understand modern delivery processes: CI/CD, Git branching strategies, feature flag-based development, and so on.
- Learn at least the basics of the most popular software development processes (Scrum, Kanban).
- Get accustomed to process improvement techniques (retrospectives, project post-mortems, root-cause analysis, etc.).
- Be open to experimenting, to trying new processes and techniques. Be proactive in proposing and championing improvement ideas. But also know how to balance implementing improvements with generating business value.
Competitive advantage: Operations
The last type of competitive advantage is more efficient operations. Depending on your company's profile you may have different teams involved in acquiring, onboarding, and supporting users: sales, call center, customer success, customer support, implementation, operations, invoicing, and so on. Making these teams faster, cheaper, and more user-friendly is another way to win over over the competition.
How can you help with this as a developer?
- Learn how your various "operations" teams work: what they do day-to-day, what metrics they use to measure their success, what makes them efficient and what slows them down, how they interact with customers.
- Get a good overview of the tools to rapidly build internal tools faster: automatic admin panel generators, CMS frameworks, UI component libraries, and so on.
- Understand the trade-offs of buying vs building vs integrating internal tools (admin panels, invoicing systems, CRM platforms, inventory management and order tracking systems, etc.).
- Know how to most efficiently keep your customer-facing teams updated about the status and expected completion time of your work (for example, bug fixes) so they can easily obtain and pass this information to customers.
- Understand personal data privacy and security issues: how to make your "operations" teams more efficient by providing them tools like user-impersonation or giving them access to user data for tech support purposes without compromising user privacy.
Growth
To become successful, companies need to constantly grow their revenue. It almost always means also growing the team. This, in turn, means more recruitment effort (including onboarding and mentoring), a bigger codebase, more complicated architecture, and increased complexity of organizational structure. It also makes communication, teamwork, and management more challenging - usually to the point where top-down micro-management doesn't cut it anymore.
This sounds like a management problem. But even as a "regular" developer, you can help much more than you think.
- Learn how to modularize the codebase and architecture so multiple teams can collaborate without collisions. Familiarize yourself with Domain Driven Design, micro-services, micro-frontends, API design principles, git repository topologies, and similar. Understand how to evolve the architecture over time, to accommodate the growing size of the platform and the growing number of teams, without over-engineering it early on.
- Learn how to make code easy to read, understand, debug, navigate, and modify for other people. Understand the concept of cognitive load. Get a good grasp of clean code principles.
- Understand what makes the whole engineering organization go faster (design systems, component libraries, coding conventions, UI guidelines, and so on). Understand compromises between what to standardize and what can be different per team.
- Learn how to communicate well (clearly, understandably, concisely, and on-point), both verbally and in writing. Learn how to effectively brainstorm, make decisions together, and navigate disagreement or conflict. Understand how to effectively sync and collaborate with the other teams.
- Find opportunities to help with recruitment. If not by directly participating in the interviews, then by reviewing CVs, preparing and evaluating coding and system design challenges, and promoting your company (through blogging, social media, conferences, or by directly recommending your colleagues).
- Make onboarding easier. Understand and use industry-wide standards to lower the entry point for new hires. Know how to document and explain architecture and logic. Be responsive, non-condescending, and open to answering all questions.
- Help with mentoring. Understand what tasks to assign to someone new or more junior and how frequently to sync with them to not overwhelm them but also not leave them hanging. Be supportive and patient.
- Take ownership of various projects, initiatives, and modules to reduce the burden on management - so they don't have to micro-manage everything.
Sustainability
Companies are long-living entities. Gaining a competitive advantage and achieving initial success is only the start of the game. A company needs to sustain its success over decades.
But when a company is under constant pressure, fighting off new challengers and chasing ever-changing market conditions, it's often necessary to cut corners. Which may put the company at risk further down the road.
To thrive over a long time, a company needs to strike a fine balance between aggressive and sustainable. How can you help maintain this balance?
- Get a good understanding of the concept of technical debt and the ways of managing it. Develop a keen eye for both under and over-engineering. Learn the patterns and principles of code maintainability and evolving complex legacy codebases over time.
- Be aware of the short- and long-term trade-offs between the development speed and the concerns like reliability, performance, scalability, security, privacy, usability, or maintainability.
- Understand short- and long-term implications of various architectural decisions (monolith vs microservices, native vs hybrid mobile, REST vs GraphQL, single-page app vs server-side rendering, monorepo vs multiple repos, and so on).
- Know how to evaluate new technologies not only by the "cool" factor but also by the learning curve, maintenance cost, ease of recruitment, vendor lock-in, long-term support, and similar. Be aware of the build vs buy vs use open source trade-offs.
- Understand how technology choices impact business and UX capabilities and how they broaden or narrow down what the company will be able to solve for its users.
- Don't just passively follow business requests. Participate in setting technical vision and direction and provide guidance and counsel to the rest of the organization.
- Learn how to maintain a healthy lifestyle and avoid burnout.
Adaptability
To stay successful for a long time, sustainability alone is not enough. Companies also have to continuously adapt (or even reinvent themselves).
A company has to adapt to the macro-scale events (changing market conditions, changing customer tastes, new technologies, economic situation, fashion, and social trends) and to the micro-scale events (finishing and starting projects, people leaving and joining, reorganizing teams or departments, adopting new methodologies and processes).
It may, again, seem like something out of the scope of a software developer. But with the right attitude, you can help much more than you think.
- Understand the core principles of empiricism, experimentation, and Agile.
- Be able to quickly pivot and adapt to new trends, tech, and methodologies. Become an eager learner. Know how to learn fast, how to research, and how to efficiently find information.
- Understand how to architect systems to make it easy to gradually migrate parts of them to new tech in the future. Learn how to effectively carry out such migrations.
- Most people dislike and avoid change. Make yourself open to it and comfortable with it. Train yourself to thrive in such an environment. Become good at adapting to new projects, teams, and roles.
- Learn how to quickly build rapport with new people.
- Be open to new points of view, and for updating yours in face of sound evidence.
Bottom line
A purpose of a developer is to make the product and company successful. That's why we're hired. That's why we exist. And modern software is so complex that this process can't be micromanaged. We must proactively contribute to the company's success. Become the experts on the topic.
If you understand the holistic view - what makes companies successful, how the software fits into this puzzle, and how you can influence it as a developer - you'll be invaluable. (And it also opens the door to a future leadership career.)
Plus, it's much more satisfying to understand the whole picture than to just blindly follow what you're told.
Don't want to be just a code monkey? Read my "Definitive Guide to Becoming a TRUE Senior Dev" (FREE on GitHub).
Top comments (5)
Honestly, it sounds like a true scottsman fallacy to me
en.wikipedia.org/wiki/No_true_Scot...
Yes sure it's nice to learn all those things. But we aren't genius who know it all. We learn things little by little and learn to collaborate with people who know things we don't.
You don't have to learn (or do) every single one of these things. My intention was to show the wide range of ways in which you can contribute to your company's success.
The key point for me is the mindset. There are developers who just want to get the detailed requirements and passively focus on writing code. Then, there are developers who prefer to get a user problem description and actively participate in finding the best solution. Finally, there are developers who learn about their company's business and proactively search for "win" opportunities.
I believe a professional developer (or, in fact, any professional - not just in the software development industry) should be at least at the "active", and preferably at the "proactive" level of this spectrum. When I hire a professional, I expect them to solve my problems, not to require micromanagement and have me plan their work for them.
A great example comes from the recent renovation of my apartment. We spoke to different electricians. One of them asked me which models of lamps and outlets I wanted and where to place them. The other electrician interviewed my entire family about our daily routines and activities, and then proactively proposed a solution to accommodate our needs. Guess which one I consider to be a professional?
It doesn't contradict what you have written about not being able to know it all, and about collaborating with people who know the things that you don't. But it requires a different mindset and skillset to be an equal partner with these people, devising together an optimal solution, rather than just executing their detailed requests.
The way I talk about that is this Cab Ride analogy from Jonathan Stark
jonathanstark.com/the-cab-ride
You can be either a robot, a technician or a fixer.
What do you choose?
A great article and a beautiful analogy! The Robot/Technician/Fixer personas are exactly what I meant when I mentioned the passive/active/proactive approach. Thanks a lot for sharing!
There's an interesting remark at the end of the article: "None of the three is right for every client situation. The right role to play depends on the client’s needs".
I'm personally biased toward the Fixer/proactive attitude for two reasons: a) As Jonathan Stark writes (and from my experience as a developer), it's the most profitable and satisfying role of the three. b) From my experience managing an engineering team in a fast-moving startup, Fixers allow the company to iterate the fastest, with the lowest management overhead. But it's true that it's not universally applicable in every situation.
Thanks again for valuable insights!
I cannot stand being micro-managed and I'm easily bored in the role of the technician.