DEV Community

Discussion on: What are your thoughts on the whole 10x engineer viral discussion?

Collapse
 
keithy profile image
Keith • Edited

Robert Glass wrote about the 28x programmer about 30 years ago. I beleive that it is possible in many fields.

However, it can depend upon what you are counting. In many fields the bean counters get it wrong, and the truth about productivity and effectiveness is counter intuitive. The 28x guy may simply be the one to be pig headed and stubborn enough to stick to his guns and make good decisions.

Robert Glass also said that the productivity of those that stuck to an old tried and trusted technology for 10 years was usually as good as, if not a lot better than those who followed the latest fads.

In one company we studied, the production manager requested permission to extend the shop floor to cover the Director's car park. When asked what he wanted to use the extra space for, he replied "nothing", but it will help us double our productivity. Explaining, he said that the space would help them with much needed flexibility in a plant that was already running to capacity 24/7. It takes some pluck to ask the CEO for his parking space, and these are the guys that know something we dont.

In coding there are many factors that can be combined to get your 28x.

Your choice of programming language, one with clear simple rules vs no exceptions or gotchas.

Smalltalk has clear unambiguos rules and everything is an object.
PHP/Javascript have many gotchas. There is a 5x difference right there.

Debugging tools, make a big difference. In Smalltalk if the debugger comes up you can fix the code, and hit continue without stopping the execution. You can even code in the debugger. I would give debugging in smalltalk vs PHP/Ruby another factor of 2-3. (actually in practice its more like 20x better)

Readability and its impact on maintainability is another factor of 2-3. Why all of these Java based languages thing that blah(1,2,3) is a readable format I have no idea. Smalltalk's sentence structure can be genuinely readable. (a between: 2 and: 5)

The ability to write your own abstractions and Domain Specific Languages can win you another factor, sometimes as much as 10x. Just look at all the ways that ruby has been used as a DSL.

Wherever there is a conceptual change or interface, there is another barrier to productivity. For example, having your data in an SQL database introduces another language, interfacing libraries, ORM layers and added complexity.

In an Object Oriented Database, where your objects just save themselves, and persisence is transparent and automatic, schema migration is automatic, and transactions are also supported, you get a 2-10x factor right there.

In the 1990s I was shown a programme in which the UI was emailed to Sweden, and the programme carried on working. Objects messaged each other over the internet, and distribution was built-in and seemless. (Papers on distributed Smalltalk go back to 1990.)

What has happen since is that more and more layers have been added, in 1980 Smalltalk was the operating system, and it was the abstraction for everything. It was all one layer. (Now we are using the Javascript VM for this purpose, web assembly is the new target OS)

Since 1980 we now have, the hardware, the micro-kernel, the kernel, the OS, the container orchestration, container runtime, the container, the kernel, the os in the container, the programming language, the database interface, the database, the api server, the api client, the programming language, the vm, the DOM, the css, the websocket/ajax, the client storage etc etc. Layer upon layer, of different technologies and learning curves. Things have gone backwards in a big way.

In coding there are lots of different hats that can be worn, user, tester, author, builder, programmer, architect. At each level diferent technologies prevail, and there is a learning cliff that you need to climb to move up a level.

Your 28x guy can operate at the level of an architect, and so can build the flexibility in to the architecture if they get it right.

Smalltalk is an environment that allows you to operate with all of the different hats on, at all levels, in the same language. You can script a spreadsheet, or write an object oriented database, or invent TDD, MVC, DCI architectures. ST/X is a smalltalk in which you can program your methods in C if you wish, and they are compiled and dynamically linked in.

So if you take long build times of static languages and put this up against the no build time of ST/X (which is still compiled via C) you win another 2x.

Finally, an environment that captures and displays the knowledge of everyone that has gone before over what is now 40 years (since smalltalk 80) and let you browse it and learn from it, will give you such a leg up, you get to build on the shoulders of giants.

In conclusion, I am saying that in principle tools make a huge difference, so any programmer that can be stubborn enough to stop working on the problem that they have been given, and to build tools and abstractions instead that smooth out complexities in that domain, can if they get the time and the space to work at the best of their ability deliver on the 28x promise.

As tools generally get better, debuggers actually work, and abstractions get simpler, we all get better, we all benefit.

Some have commented that many of us here have never worked with anyone that is 10x. My hypothesis is that this kind of advantage is tools and architecture driven. I presided over a simulator project that was developed in parallel to another project, and we did with one guy, what 7 failed to do with other technologies in several attempts, in weeks rather than years, simulating 1000s of equipment rather than 10s, on one server rather than 10s Many times it is about picking the right tool for the job, and building on these strengths.

Now checkout this guy in argentina: Alejandro Reimondo, he has a single development environment that deploys to .net, javascript vm, android, lua vm, ios, native cocoa, and osx. In theory theres 100x right there.