Adaptability
I am sure that each of us thought more than once about what awaits us in the future. I am not going to waste your time on useless, mostly reflections. Rather, I would like to cheer you up (fasting after Friday) and draw your attention to the importance of strategic planning of your life using a good example.
Hereinafter, the largest collection of translations of wonderful comics Geek and Poke will be used.
')
A curious and completely realistic example: Dave Rooney wrote about his life:
Recently, on Twitter, I participated in a conversation that the obsession of software developers on their tools borders on religious fanaticism. Understand me correctly - good tools increase the efficiency of developers, and their productivity, in turn, depends on the extent to which they have mastered their tools.
However, it surprises me that we work in an industry in which changes are not only normal but also expected. The rate of change is constantly increasing and is not going to decline. This is strange, because developers seem reluctant to replace their usual tools.
Perhaps my view is influenced by the fact that I worked as a contract developer in a significant part of my career. As a rule, they introduced me to the course of a new task, showed me what machine I would use, told me what development environment the team, source control system, etc. were using. I did not have the freedom to choose - either I accept the terms or look for a new contract. I admit that I never refused a contract because of the tools.
Here is a list of environments in which I have been working since I started writing code:
30 years ago (1983)
25 years ago
20 years ago
15 years ago
10 years ago
5 years ago
Now (2013)
Sublime Text really does quickly index and text search among thousands of files, but these are flowers compared with the ability to find a definition of a method on Eclipse or to bypass the class hierarchy. I can write macros in Sublime that can automate repetitive operations, which I liked in Textpad and was sorely lacking in the IDE. However, I do not have automatic refactoring available in Eclipse and NetBeans.
When I watch the developers working in Vim and Emacs, it seems to me that I look at the virtuoso performance of the pianist - the whole process looks so relaxed! It amazes me that these tools are more optimized for writing code than for analysis and refactoring.
The mere suggestion to use others - other than Vim and Emacs - the tools will cause serious excitement. But from my own experience I will say that it is not so difficult to adapt to new instruments. Of course, it will take time, you will have to get some skills, forget others, but the flexibility is worth it.
However, not the fastest or the smartest survive, but the most adaptable to change.
Successes in very difficult, as it turned out, business.
Sources:
Hereinafter, the largest collection of translations of wonderful comics Geek and Poke will be used.
')
A curious and completely realistic example: Dave Rooney wrote about his life:
Recently, on Twitter, I participated in a conversation that the obsession of software developers on their tools borders on religious fanaticism. Understand me correctly - good tools increase the efficiency of developers, and their productivity, in turn, depends on the extent to which they have mastered their tools.
However, it surprises me that we work in an industry in which changes are not only normal but also expected. The rate of change is constantly increasing and is not going to decline. This is strange, because developers seem reluctant to replace their usual tools.
Perhaps my view is influenced by the fact that I worked as a contract developer in a significant part of my career. As a rule, they introduced me to the course of a new task, showed me what machine I would use, told me what development environment the team, source control system, etc. were using. I did not have the freedom to choose - either I accept the terms or look for a new contract. I admit that I never refused a contract because of the tools.
Here is a list of environments in which I have been working since I started writing code:
30 years ago (1983)
- Apple Command Prompt; spelling of BASIC and assembly code.
- Few editing functions, but the less you know, the better you sleep.
- A year later, Sed or a similar editor was installed on the mainframe of the university using FORTRAN.
25 years ago
- xedit on the IBM mainframe with REXX.
- It was a decent full-screen editor that could be automated to provide a full-screen user interface for mainframe applications.
- I also used vi for some purposes, which seems cumbersome and backward compared to xedit.
20 years ago
- I used the editor for, not surprisingly, the C language and several others.
- The editor was easy to use and I read it quite well.
15 years ago
- I worked in Powerbuilder, Visual C ++ and Visual Basic integrated development environments.
- Editing outside these tools was inefficient and risky.
- I got the hang of working with them.
- IDE editors are well-suited for work.
- Also used vi, launching remote command lines (remote shells) on Unix systems.
10 years ago
- Different Java IDE: PowerJ, JBuilder, Eclipse depending on the standard of the client organization.
- Performed tests in IDE.
- Used Textpad to edit text outside the IDE.
- In terminal mode on a remote host, used vi.
5 years ago
- Used Eclipse and NetBeans for Java, Visual Studio for C \ #.
- Performed tests from IDE.
- Used Textpad for text editing.
- In terminal mode on a remote host, used vi.
Now (2013)
- Sublime Text 2 for text and code editing.
- I run tests from the command line.
- In terminal mode on a remote host I use vi.
Sublime Text really does quickly index and text search among thousands of files, but these are flowers compared with the ability to find a definition of a method on Eclipse or to bypass the class hierarchy. I can write macros in Sublime that can automate repetitive operations, which I liked in Textpad and was sorely lacking in the IDE. However, I do not have automatic refactoring available in Eclipse and NetBeans.
When I watch the developers working in Vim and Emacs, it seems to me that I look at the virtuoso performance of the pianist - the whole process looks so relaxed! It amazes me that these tools are more optimized for writing code than for analysis and refactoring.
The mere suggestion to use others - other than Vim and Emacs - the tools will cause serious excitement. But from my own experience I will say that it is not so difficult to adapt to new instruments. Of course, it will take time, you will have to get some skills, forget others, but the flexibility is worth it.
However, not the fastest or the smartest survive, but the most adaptable to change.
Successes in very difficult, as it turned out, business.
Sources:
- Adaptability Article
- Project Oh, these developers
Source: https://habr.com/ru/post/194528/
All Articles