Twenty years ago, I worked in the field of technology, ten years later I moved to management, and now I’ve returned to technology again, this time in the role of a consultant. Some of the changes made me very happy, while others surprised me just as much. Below I will briefly talk about those main things that almost killed me in the prime of life.
Nice first: Unix and developers reunited
Throughout the 1980s and early 1990s, most professional software development was done on expensive Unix workstations such as Sun Sparc or NeXT. In the nineties, the market was captured by WinTel and everyone began to code on Windows using tools from large vendors, such as MS Visual Studio, or a few free options such as Eclipse. Linux at that time was still considered something more for hobbyists in the desktop world.
In 2001, I worked at a startup. There was a single Linux developer for our entire team, and he had a hard time cutting off access to version control tools and the Outlook email client. He usually sent us a code by letters and asked to fill in for it. I remember that I myself was then using XEmacs - eh, the good old days.
Fast forward to the present. Unix has become a very popular platform among developers, especially those on the Mac, due to the fact that it uses the Unix kernel. In addition, there is such a thing as Linux on Windows. In this respect, unlike many others, my return to IT was not fraught with any difficulties. It's funny that many of my young colleagues now barely manage Windows, and on Linux they feel much more confident.
Release management is no longer a profession
Once upon a time, branching, merging, and resolving conflicts was a hell of a job that often required the intervention of a dedicated release engineer. In the days when ClearCase reigned in the version control market, there was enough fork, merge, and release work for a large team - at least in my experience at HP in 2002.
The idea that a developer can submit change requests himself is actually quite young. Apparently, she was given the beginning of the transition of development to Linux and a new wave of distributed version control systems: BitKeeper, Git, and so on. Legacy systems like ClearCase, CVS, SVN or PerForce did not have the ability to make their own changes so that they would be reflected in everyone involved in the workflow. Either the repository owner did it, or the person in charge of release management, or each developer organized everything for himself. Now the process has been greatly simplified, and it is now possible to establish joint work in a team without additional participants.
Where are the QA teams? Unit testing and continuous integration
I first heard about unit testing and continuous integration from Kent Beck, one of the authors of the Agile Manifesto and creator of the extreme programming methodology . Twenty years ago, his ideas were revolutionary, but they did not immediately achieve the status of a standard in development that they have now.
In my opinion, it's a shame that there is no more emphasis on continuous integration in Agile and Scrum. But I am already glad that this practice has become quite popular today. I attended that conference and I remember Joshua Bloch, author of Java Collections, stepped on stage to talk about continuous integration, and he said, "Thank you (Agile or JUnit) for giving continuous integration a charm." And he was right. In the old days, writing tests was considered boring, and few people did it. Therefore, the bosses hired special people, QA engineers, who were looking for errors for the developers! Go crazy, that lafa was ...
Unit testing and continuous integration have almost eliminated the need for such people - now developers are responsible for writing tests themselves, and the continuous integration infrastructure launches everything on time and reports errors. This makes the software more reliable and shortens the development cycle. Also, the innovations helped developers to gain a more holistic view of things and learn how to write code so that it can be easily tested.
Docker: no more clutter on the way to production
Containers, namely Docker, have removed all the unnecessary from package management and minimized the environmental problems that arise as the code passes tests and goes into production. Previously, however, you will have to get a good DevOps engineer to set up the Docker ecosystem.
In the old days, it happened that the system was created in a completely different environment in which it was supposed to be deployed (well, that is, for example, they wrote code on Windows and deployed on Unix). This inevitably caused bugs and piled up additional work in each test-release cycle.
In addition, in the past, a release, testing or DevOps specialist would take code from a tag in source control and decide what to do with compilation, testing, and migration. Usually, this would reveal a whole bunch of hard-coded paths and variables, missing libraries and files that needed to be reworked or tweaked to work properly.
Docker simplified the process and created conditions for continuous integration and continuous deployment by, again, putting the relevant functions in the hands of programmers.
Open Source: Too Many Possibilities
In the world of open source software, the choice is now, frankly, in abundance. I was setting up Jenkins here and wanted to integrate with BitBucket. A search for plugins for “bitbucket” yielded more than four hundred results, many of which are open source.
This creates two problems:
- More difficult to choose from a large number of options
- With such an abundance, some of the instruments will definitely die out and their support will cease.
But there are also pluses: there is almost no need to make the basic infrastructure and tools yourself - find what you need from the ready-made, and use it. Twenty years ago, you had to write libraries and data structures for the most common operations, and it was even fun somewhere. Today, there are so many different libraries and frameworks for each language that 99% of developers can live without writing a single B-tree, or hash table, or even an OAuth connector.
Agile and Scrum have taken over the world
Twenty years ago Agile was already alive and well (the Agile Manifesto was released in 2001), but its popularity began to grow later - including outside IT, and sometimes in a distorted form. He became a favorite adage in executive circles: "Business must remain agile, otherwise it will not survive."
I remember the times when the release cycle went on for quite a long time (three months, and this is in a startup). After returning from the meeting, at which he parsed the specifications line by line, the developer could sit down at the table and quietly gamble for several weeks without worrying that he would have to report on how things were going. And now every day stand-up rallies, every two weeks sprints - you can't really relax!
Agile also redistributed administrative functions - now developers communicate directly with users or product managers. Sit back in silence will no longer work. Accordingly, the ability to communicate has become much more valuable than before.
Finally, the pace of development has accelerated with Agile. It's not even about stand-up meetings and other Scrum ventures. The tools themselves began to save us time: whiteboards in Jira, change requests, tools for continuous development and deployment - all of which make it possible to work faster. On the one hand, this adds to everyday worries, and on the other, you feel the return on the fact that you roll out the products in a short time and complete tasks in a comprehensive manner.
Finally
If you also left IT and are thinking of returning, I support you and wish you good luck. Personally, I gladly updated my skills (although I almost died along the way). The fundamental principles of programming have remained the same, so I think I'll make it through somehow. But the toolkit has changed a lot, and this affects productivity.
You probably caught a recurring theme in the article: a modern developer has a much wider range of tasks than twenty years ago. He writes code, does version control, tests what he wrote, works with containers, and so on. Of course, the brain sometimes boils, but you no longer need to make linked lists yourself.