I regularly interact with a wide variety of candidates right from college graduates to very senior engineers, one story that I keep hearing is that every one prepares a lot for the interviews solving DSA problems. It is like rote learning, one has to keep practising a lot just for the interviews.
I have never understood the need to test the depths of programming for regular software development. Software development in most cases require skills that does not need deep understanding of data structures and algorithms. A fundamental knowledge of programming is enough. What is needed is communication skills, it is extremely hard to specify software requirements in writing just like how input and output are expressed in competitive programming.
A programmer’s biggest challenge is to understand the value and intent behind a requirement, what impact it can create for the business and come up with a solution that is easy/quick to develop, maintain and extend. The main point here is, it should be fast/easy, cheap to develop/extend, should be maintainable and not be hard to fix when critical flaws like zero days surface. Communication, discipline on keeping up with clean code, grit to keep the code continuously tested, integrated and deployable are key skills. Product owners will need multiple iterations and increments to get to a desired state; faster and easier the communication then faster is the desired result.
A big myth in hiring space is that if programmers are good with DSA, then we can throw any problem and a deadline at them and we can achieve a lot. This mindset is the root cause of a lot of software rot, making it extremely hard to onboard new developers and keep existing developers productive. My observation has been that candidates tuned so well to crack DSA problems expect clear specifications often broken down to LLD and tasks with clear input and output. They find it very hard to collaborate with peers or train new developers. When they face ambiguity, they go haywire instead of resolving it; often end up treating it like competitive individual sport whereas software development is a complex creative process.
A lot of people quote about Henry Ford’s remark, “If I ask my customers what they wanted, they will say faster horses”. We do not know if he really said those words but it is true that many of the ideas will always be incremental and not inventive, be it technology or ways of working.
If you ask bosses what they wan’t, everyone unanimously says “Longer working hours” especially more vehemently in the software development industry. My observation has been that with lots of automations and tech abstractions, the time taken to develop software has come down by a few magnitudes, compared to what it was a decade ago. What needed large teams with extensive management overhead can be done with smaller teams with fewer oversight.
In mature domains like mechanical and civil, breakthroughs are very less frequent; hence templating the work into easy to do steps that are verifiable by non techies is very productive. An abstract requirement will be translated to actionable steps, broken down into units of work and assigned to people to complete. Once the task is complete, it is very easy to verify by anyone else and the end of construction phase is typically the end of the project. It makes things rigid and predictable, so it has a linear relationship between number of people, number of hours and dependencies.
Software development on the other hand is very difficult to convert from abstract to concrete, any infusion of rigidity risks not getting the intended outcome. The combination of ever improving tech landscape, difficulty in communicating what a working software should do, the nature of knowledge work which degrades when stressed, makes it very hard to have a proven relationship with working hours, number of lines of code and number of people.
When dealing in a dynamic environment, there is more than one way of doing things, sometimes exponentially time saving ways can be found if we strive to make the design simple. One personal example I had was to write a program to convert roman numbers to decimal. I wanted to shake off the inertia and start writing code, I dived deep into the code thinking in terms of objects, writing a lot of tests and completed it after a few hours when I was convinced that the solution is complete and clean. The next day I realised that I was constrained by the need to keep going, that I never questioned if my solution could be simpler. I just spent 20-30 minutes to rewrite it in functional paradigm and got that done under 10 lines of code in one file which was 100+ lines across multiple files. For an outsider, thinking hard about the problem looks like inactivity, wasting time and not showing urgency; to me it came down to a super simple solution that is very easily be read and maintained by others.
Bosses are often tuned to look for urgency and activity as indicators of productivity. Also in the software service industry irrespective of the productivity, the number of hours billed directly impact profits; hence bosses love long working hours. In the software product industry though billing hours don’t matter a lot, the apparent busyness of people is expected. As a result, no major improvements happen as it is always business as usual sometimes even slowing down overall, creating physically and mentally unfit individuals over the long run.
On the other hand if teams are given freehand, then they also tend to extend the thinking phase into analysis paralysis. This can be broken down by mandating outcomes and impact on fixed timelines than output and effort. It is an art and takes a determined effort to build high performing teams that keep punching above their weight. The easy way out is demanding long working hours.
If you are engaging a knowledge worker on physical effort, then you are buying into mediocrity
Cost of living changes and salary changes will never match. It is a never ending debate because of the disconnected way in which the cost of a basket of goods and services change. In India, in the last 20 years, petrol price has risen only 3x but gold has risen 12x which people compare it to a standard way of thinking about inflation but it is not, as it is also a commodity backed by demand and supply.
By comparing the absolute number cost in the last 20 years, vehicles cost about 2x, petrol 3x, clothing 3x-5x, food 5x min in staple raw material cost, almost 10x in green groceries, rental and property 5-10x, phone bills 0.7x, feature phones 0.3x, in general electronics & communication – more features and lesser cost. For a basic living it is generally considered that we have good food, clothing and shelter. In that sense the cost of living has gone up around 5x-7x for most of us. There are some services like hospital and education which have increased the spectrum on both ends thereby making it difficult to assess but in general we can say that also falls in the 5x-7x bucket. We spend a significant amount of money on the basic expenses so 5x-7x change looks a good ballpark.
The inflation data from across the world suggests that India went through an inflation of around 4x in the last 20 years. This data takes a wide basket of goods and services not just the basic few we have looked at. With that in mind if I compare to the wages offered 20 years ago. The big IT companies in India provided an average entry level salary of 2.1 lakhs per annum in the year 2004. This is for a person just out of college without any experience. The range was something between 1.5 to 5 lakhs per annum. If this was the case in 2004, as per the economists figures in 2024 should be around 6 to 20 lakhs per annum for fresher programmers. If we use our 5x-7x yardstick then the number jumps up a great deal. In reality salary numbers do not keep up.
Why do not salaries keep up with the cost of living? The answer is demand and supply. In the early 2000s an entire state of Tamilnadu produced programmers who have good comprehension and coding skills to just fill up a small office building year on year (In 1000s to 10,000s). Initially companies were so choosy that it was difficult to appear even for an interview if you are not from a top tier college, slowly they moved to lower tier colleges and by the end of 2000s massive walkins were encouraged to hire talent. This trend disappeared when the supply caught up for freshers leaving the salaries stagnated as there were more freshers than available jobs.
It applies in other fields as well, my neighbour who was owning and driving a taxi which was semi luxury 20 years ago earned around 20,000 rupees a month in profit. The cabs and drivers supply hit more than the demand that now the same person will barely make 1.5x to 2x of that money. The only way for us to keep be on the happier side of the cost of living is to create a demand for our skills. A lot of freshers do the mistake of early specialisation, choosing a well paying tech job in a narrow field which works in the immediate future but locks them up forever in a stagnant skill set.
I keep repeating this statement – software development is about communication of different systems built by different teams. The more things the software does, the more overhead it has, to deal with people and process. For us to get a hang of what is going on in the overall landscape, it is possible only if we have explored the lengths and breadths of technology and tools. It is not necessary to be an expert in each and every aspect, but should understand them in first principles. A developer who spent their early years working in UI, backend, infrastructure, mobile development, data engineering and using different programming languages like Javascript, java, python will have a thorough understanding of the tech landscape. The same developer when working on legacy projects, green field development, brown field development and maintenance will gain enough experience on people, process and engineering in the long run to become a VP of engineering compared to someone who specialised very early in a tech because that was hot.
With AI coding assistants growing in capabilities, there is now even more demand for generalists who can grok and handle a lot of things in the length and breadth. Avoid the temptation of now and plan for the long run, a career is not over in 10 years. Flexibility in the early years and learning compounds to a great growth in the long run.
Novi's 