Nowadays, most developers unintentionally focus on short-term goals and tasks. Start-ups and fast-growing companies tend to impose tight schedules on feature releases, and context switches occur too often to ensure code quality longevity. Thus most code written is good enough to ship, but, after some time, is difficult to understand. Why is code written this way? How does one maintain it going forward? Who are the talented engineers start-ups need?

Some developers, looking at such code written under tight schedules, will likely consider rewriting it from scratch. Why? Because time pressure makes code messy, uncommented, untested, and unwieldy. With the extensive languages and technologies now available, it’s often easier to recode something using existing modules than to spend time understanding something created by someone else just to change or enhance a feature.

It generally is not worth it to maintain the small pieces of code found in software demos, raw MVPs and other similar stuff.

Modern application development is not about thinking about code for two weeks and then writing it in two days. It’s now more a reversed process. Application engineering nowadays is a sport, where reaction time is crucial to creating beautiful code with long-term goals in mind. Developers who can adapt to this new flow tend to survive/perform better over those colleagues who got used to thinking a lot about their code before writing.

The good ol’ days of thinking for too long are gone. Time-constrained development is now the core practice amongst software developers.


Reaction time is the most important factor now. The faster you can see the overall picture of the future application, SDK, or framework in your head, the sooner you can actually code it. Planning on paper is a thing of the past, and drawing UML diagrams is something that nobody would likely do right now, even when thinking about huge enterprise companies that ship even more complicated software.

Pondering the architecture of the application on paper is futile now—modern programming languages and development practices are to blame. Straightforward programming languages like Swift positively incline developers to write self-documenting and self-organizing code as-is, without hours of preparation. Why use UML diagrams when the programming language is already good enough to read?

When it comes to developing huge and complex applications, it is generally never about creating any sort of documentation because of the actual product. Great developers already know that any big chunk of software can be split into smaller parts, isolated, and abstracted from other layers of the software machinery.

Let’s take for instance  Adobe Photoshop, one would never consider developing it from scratch, as it’s monolithic and designed using a single diagram of relations between parts of applications. It’s not like opening an editor and writing 10,000 files that maintain internal relationships between modules. It’s about seeing the intricacies of need within the image editor: importing visuals, accepting user input through a GUI, backend image processing user input, and exporting pictures to disk. Thus, separating concerns is the first item to study and consider when it comes to developing any kind of software.

It’s always good to understand what an application must do from the user’s perspective, but it’s never a good idea to start developing it from such a perspective.

Procedural, object-oriented, functional, protocol-oriented programming techniques—all of these serve the purpose of organizing the code, but it rarely matters which paradigm you use to organize your code. What always matters, however,  is how well you divide your application machinery into smaller parts.

This is the moment when reaction time becomes the most important factor. Since developers now have less time to think, seeing the whole picture and then dividing it into smaller harmonious parts is the most crucial component of this new quick application development cycle. The faster you see the right way of splitting up the app into sub-parts, the sooner you can start coding one of those parts (while still thinking about others).


When developers hear an idea for the first time, they should avoid thinking about the idea as a whole, but instead organically separate parts that are shared within the idea. Total time to implement any idea is the sum of times needed to implement all of its parts. A developer might not know how to implement  a speech-recognition bot for order pizza, but they do know how much it takes to gather voice input from a user and send HTTP requests to a remote server to place the actual order.

Fast abstract thinking, when it comes to software development, is the most important skill of an engineer. Less time spent on thinking about an entire idea is converted into more time implementing what is already known.

The core of any application or framework, even if it contains new brilliant ideas, is still the smallest part of an application’s implementation, which is usually well-hidden under the input, output, and user interface layers. Most developers already know how to deal with this kind of stuff.

Time-constrained application development, of course, is very cruel to engineers who are slow to strategize, or who believe that good code only comes after hours of thorough thinking. Software programming practices were good enough when we had more time to think about the code before composing.

It’s now time to actually code, and thankfully, we have all the necessary tools to not only do it fast but beautifully.

Time is the most notorious factor that puts tremendous pressure on software engineers. Less time to think demands a faster reaction time to achieve stable results that last longer than a single release cycle. But where do you find the right people who will be able to cope with this kind of mission?


The answer is simple: there is no need to look for the perfect talent to achieve company needs. It’s nearly impossible to find brilliant engineers. They are either already owners of their own start-ups, or they work for someone else. Finding the right person to solve modern application development tasks is like searching for a needle in a haystack. AngelList, StackOverflow, or HR agencies can only scratch the surface and observe  people who know the basics in computer science or engineering.

Whoah! It’s nearly impossible to find brilliant engineers. Thing is, they quickly become CEOs by founding their own companies. As their companies grow, they start looking for other talents and the cycle continues.

Small companies, consisting of less than five people, don’t actually need to aim at finding brilliant engineers. They are so rare, it would be a miracle to find even one. Creating great bonds within their companies when it has just started is more crucial than technological advancements pushed by brilliant software developers. The software doesn’t need to be perfect to start, but the foundation of the company must be solid enough to support further growth.

The internal culture of a company, when it’s recently founded, is like a ‘cosmic soup’—it needs perfect initial conditions to shape the future of itself.

It takes some time for a company to grow. During this time  engineers that are already in the company tend to  advance levels as the company evolves, they start utilizing tools they had never touched before. This whole process is akin to evolution. Though the company might hire new developers, the old ones must continue to grow and already be aware of all the technologies related to the company’s mission. Objective-C developers must not stay Objective-C developers two years after their on-boarding—they have to start learning new languages, new technologies, new paradigms, and new techniques. If they do so, they become more powerful, and can make more insightful decisions to guide newcomers.

At this point the company actually doesn’t need to seek brilliant engineers from the outer worlds anymore. The company is now a factory of brilliant engineers shaped exactly to pursue the core mission of itself.

What does this mean?

  1. The company does not need to only target brilliant engineers when hiring from the outside.
  2. The company can now hire people who have mastered the **craft** of software development (they know programming languages, necessary tools, and have the ability to swiftly and organically communicate with other developers).
  3. The company can ask its own brilliant engineers (either founders or other engineers grown by founders) to mentor other brilliant engineers from the inside.
  4. Since newcomers already have knowledge of programming and communicating, it’s merely a matter of time and teaching them the right way of using tools to achieve the right results.

This last step doesn’t sound easy at all. Nobody says mentorship is the easiest thing to do, but it’s the most important one if a company wants to grow even further.

Brilliant engineers can become great mentors if they know how to communicate their knowledge to newcomers. These kinds of engineers are the ultimate knowledge bearers and managers inside a company. They are able not only to craft but also to teach others their craft and thus spread their understanding of the internal machinery—leading to the ultimate growth of their company.

Growth in a company when it comes to talent lies in spreading as much knowledge of its internal processes as possible: senior engineers teach junior engineers, juniors become senior engineers themselves, rinse and repeat and growth continues.


So, how do you on-board new software engineers and avoid confusion with this overwhelming amount of information?

  1. Know the role exactly for which you are hiring. Companies are just as modular as software: they can be split into several parts, and each of them can be pretty much independent of one another.
  2. Assign new hires a mentor. It’s best not to overwhelm mentors with too many newcomers as their time resource is not infinite. Maintain 2-3 newcomers per mentor.
  3. Ensure each mentor and  newcomers get acquainted with each other. Personal relationships and communication is crucial to establishing friendly relationships within the company. Private communication between a  mentor and newcomers can be more efficient than group chats because it is always a more relaxed environment.
  4. Make sure the mentor and their newcomers schedule chats to talk about their plans to spend time together. It always feels more natural to talk to colleagues and discuss code issues, architectural problems and assigned tasks.
  5. Mentors can act as  first project managers for newcomers and can pretty much assign tasks (on a per-application basis) and do status check-ups. In this way, mentors become an invisible transparent project management party, which is actually on the same hierarchical level as the new developer. The tasks that are assigned and checked for are actually an exchange of experience and knowledge, and can be useful for both the mentor and the newcomer.
  6. The more time passes, the more independent the newcomer becomes, spending less and less time with their mentor, becoming a more  self-sufficient and confident programmer who can do any kind of task (within their area of expertise) on their own.
  7. The mentor is then free to have another junior engineer to spend time with, bonding with yet another member of the growing team.

The time-constrained environments of modern software development mean that software engineers hired by the company must be shaped by the company’s team members for best fit.

It’s almost impossible to find the perfect fit from the outside world as opposed to growing it internally. It is still possible though to find very efficient software engineers. They can always work on tasks that don’t require deep knowledge of their company’s mission, but they also almost never contribute to the evolution of the overall knowledge within the team.

Software engineers that work as the grease for their companies clockwork are exactly those aforementioned mentors that can make sure newcomers are never stuck and never idle when performing their first day-to-day tasks. Altogether, a company needs to have just enough grease to make sure its technological machinery is running smoothly, especially when it comes to engineering talent growth.