And programmer reading anything on his blog, or anything on HN for that matter, is not an average programmer anyway. The simple fact you are interested in your work singles you out.
Guys, you need to come out of your super power bubble and come to work down here. Where people uses PHP, SVN, and don't know what an environment variable is. Where they work for money, not for passion. Where Vi is scary and they pay the licence for Oracle even if their DB has one table.
This is the huge majority of the devs : plumbers.
I find it disrespectful when people don't realize this, because it means they live a life ignoring a vast majority of dev tool users.
Not only those people are numerous, but they create a lot of wealth because they are so many.
Don't assume:
- devs know the command line
- devs know how to setup a server
- devs know how to use a package manager
- devs know how to version control, unit tests...
And above all, if they don't know how to do that, don't assume they can't do their job. Because according to their employer they do. And they are paid for it.
They won't do a graceful reload, they won't compress their css and won't escape the user input. But the website will be online, serving customers.
This is why on my blog I have articles explaining what's javascript, what's RSS, how to setup the Windows PATH, etc. Because for important tutorials on Python, I can reference those, not assuming people know what I'm talking about.
Like how the Turing Test was rendered obsolete because online comments (e.g. Youtube) became so bad, the bar to writing a bot that passed as one of them was lowered dramatically.
*old song, according to Youtube comments is every song recorded before 2016 AD.
Heck even the large recent trend among app developers and business analysts for low-code tools, tools that require mostly GUI and some code to get pretty complex applications going, offering maybe 5x-10x (or more) boost to productivity - that trend wasn't even mentioned at HN over the last few years, even though it seems like a really important trend, if you develop software or start businesses.
That just makes me wish there was a different type of community for entrepreneurs, one that is focused on democratizing creation and simplifying knowledge, in many fields - because those are the building blocks entrepreneurs work with.
For the IOT, i believe thingworx is the leader.
I recently was looking for Java based open sourced wiki software for intranets. And I read about this software called LifeRay. To most people on these forums, LifeRay is not particularly interesting (based on searching HN for LifeRay related submissions and seeing how many comments a submission gets). The market size for LifeRay might be quite large, I don't know, but it is just not the kind of tech that people are excited enough to comment about. For example, I am fairly sure no one is going to go and read about LifeRay just because they read this blurb.
There are many different reasons for the lack of excitement as I am sure you can imagine. But the echo chamber is not the cause of the lack of discussion. Some topics are not just interesting enough, and probably never will be.
But the issue itself is more interesting: first - it's a big and relatively common software design problem(for example see how often visual "coding" is discussed) - how to enable common people to build complex systems. So what are the approaches being tried ? How are the better/different/worse/etc ? what could we learn from them ?
Second - what does it mean to the software engineering profession ? to freelancers ?
Third - what are the implications to entrepreneurs ? what kind of new opportunities does this open ? could this make large corporations agile enough to make it hard for startups ? what are good strategies ?
On the other hand, often you see here discussed some toy programming language that someone made(which is a cool project), but the improvements are quite small, the implications are quite small, and the major reason people find it so interesting is the bubble.
Also, I don't get what I seemingly did not realize (mostly helping clients with legacy code on legacy platforms in legacy organizations to improve their quality and teamwork), or why this is disrespectful...
Of course it was not. If you are antirez, you will mostly work with people on projects which, by nature, will involve talented programmers.
> Improving how the team works together / how work flows through the system probably has a bigger impact than raw programmer output
But only a person good enough can do that. This is catch-22
> Improving the quality of your software (minimizing defects and rework) will improve the output of everyone in the team
Yes, but it requires a really good dev to create and execute a plan to progressively enhance it. Instead of doing another from scratch which will also fail.
> I have heard of cases where removing the "top programmer" from a team made the whole team more productive
Yeah I heard of people stopping vegetables and living fine as well. And "top programmer" <=> "top dev". You can be very good at software and terrible with people.
My point is, the entire article is build on assumptions from the "top programmer" perspective.
All that goes to the water when your team is composed of:
- a senor waiting for retirement
- an apprentice fresh out of a community college
- a new dad who needs money and hates his job
- a legacy spaghetti code project coded by 3 different teams 10 years ago
- and no 10x programmer to be found
It will work. But say goodbye to best practices, and all the rules Antirez is stating.
Every other engineering discipline has licensing requirements. People think software is special because the industry moves quickly, and indeed I agree that creating a formal, standard licensure body is extremely difficult, bordering on impossible, but think of it this way:
If, hypothetically, there was a proper licensure - how many people would be competent enough to earn it? We may think that there's a labor shortage now, but really, it pales in comparison to how bad things could be if all of a sudden everyone had to get licensed.
That's the real problem - most "software engineers" are not at a level of competence where they could get licensed, if such a license existed. And the industry's way of dealing with a lack of licensure is to throw more people and money at the problem, because the problem has defied all attempts to think smarter about solving it.
..., frustrating them, leaking their data, and wasting their time.
And a lot of businesses do so while providing terrible services or products. Plus people working for them have their own agendas : family, play, not get blamed, etc and won't do anything about it.
It's not specific to software. How many of you have experienced :
- a completely broken by design shower
- those "easy to open" packages that are impossible to open
- kitchen ware taking centuries to wash because obviously nobody designing them never bother to use them
- laptop with horrible sound
- shoes that destroy you feet after 2 hours of using them
?
Doing your job well is the exception, not the rule.
I am in engineering, not IT. The executive director in charge of engineering software for the company wants to own all data and processes. He HATES my project. My second week there, his underling told me, to my face, that it was his intention to kill the project I was hired to do. (Yeah, it's like THAT.) The ED convinced my boss' boss to stop me from working on my program, and hand it over to his team. That was 5 months ago.
When I was hired, this director restarted his THIRD attempt to write the same thing with contract, overseas labor. They've been at this attempt for as long as I have been here. Their program doesn't work very well. Literally every step (that they've managed to code) takes 3-5 times longer to do with their version. The engineers are refusing to use the tool.
My boss, through excruciating effort, has collected feedback on IT's tool, and made a list of things it must do in order to switch to it from mine. This "must-have" list is about 140 items long. The program manager of this competing tool finally "put pen to paper," and estimated that, using EIGHT people, he could code TWENTY-FIVE of the required items in THREE MORE YEARS.
Rough math says I'm a 100x+ programmer, and I feel pretty good about that, but I've worked with several people who are sharper.
I said all that to set this up: To the parent comment, yes, these people produce software, and use tools, and get paid, and all that. But at what cost? The other group has spent TENS OF MILLIONS of dollars for something that will take YEARS more effort to match something my boss did for a couple hundred grand. You're right, "they" don't know how to do a lot of stuff. The person assigned to pick up my project doesn't understand how work with Azure, doesn't understand the database schema (let alone the process that dictated it), and apparently can't even copy working code from the existing program to derive new features. If you want to give people credit for being able to log into a computer, and run Visual Studio, that's great, but there's quite a bit more to it than that. When these kinds of people are creating software, it'd be better to let the users continue to do everything in Excel themselves.
I guess some people would pat the executive director on the back for creating such an empire out of this one project inside a vast Fortune 150 company, but the waste just leaves me shaking my head. And the worst part is watching how my boss, very deftly, and very respectfully, has worked to give engineers a tool that will help them do their job, and improve the process, and how the person actually in charge of such things has fought him for almost 10 years now, trying to force people to use an inadequate tool which doesn't match how they work, just to say he owns it, and there's apparently no one in the company who will or can do anything about the situation, because it would take the CEO to make IT and engineering play nice together, and he could not possibly care less what software thousands of his engineers use, or if they do it all by hand, as long as profits are increasing and the stock price is rising.
I know, I know. This is not uncommon in large manufacturing (i.e., non-"IT") companies, but this example is the worst I've seen.
And you are on HN.
And you did live in the real word where people are not 10x.
:)
What kind of dev do you suppose know what you listed? A 1.5X, 2X, or 5X programmer? Surely not a 10X/Free Electron.
"x10 programmer" doesn't mean "great programmer", it means specifically "programmer 10x better than average", so simply writing great software isn't enough - the strongest man in the world might still not be 10x as strong as the average man.
Part of that was having great programmers with great habits, sure. But a big part of that was something like "Not letting your broken organization and practices break our delivery speed"
Bad org structures and practices pull developers and teams into poorer and poorer practices, like an accretion stream getting sucked into a black hole. The org itself can take a .1 dev and turn them into a .01 dev.
I guess it was to show me that I was thinking too much like a C programmer, he rewrote my program in about 10 lines of Perl.
He was always willing to listen when I had design ideas that differed from his own. When my ideas were better, he'd incorporate them into our plans.
We had a four man team that was probably the most productive one of which I have ever been a member.
This is what makes someone a good Tech Lead and/or manager.
2.) History: was assigned tasks or project multiple people failed previously and was first to succeed.
3.) Tasks and projects assigned to him/her move with reasonable speed, does not need handholding. When other people take over, they don't complain all that much and are able to continue without encountering major wtgs.
I have heard about a case where really the best programmer left, and now everybody else had more responsibility, had to learn about parts of the code they did not know previously, had to fix harder problems.
So, everybody else was getting better because the one person who could help with the hard stuff was not there anymore.
But I honestly can't remember where I heard that...
They were, as individuals, very productive, but they suppressed the productivity of the rest of the team.
* For most of my past clients, the skill / output of their programmers was not the bottleneck, even though they thought so. As long as something is not a bottleneck, there's not point in trying too hard to optimize it (since you can get better ROI somewhere else).
* Software is a team effort. Improving how the team works together / how work flows through the system probably has a bigger impact than raw programmer output (unless you are already very good at that).
* Improving the quality of your software (minimizing defects and rework) will improve the output of everyone in the team, regardless of how good they are.
* I have heard of cases where removing the "top programmer" from a team made the whole team more productive, even though an important person was missing. I don't have data to back that up, though.
Update: Thinking more about this... I have a talk called "Your Company Will Never be Agile", where I talk about how most companies actively prevent their people from doing a good job (by having policies, procedures and a company structure that is not suitable for empowered teams). And then, those same companies complain that they cannot get good people and how all the hip companies can get the 10x programmers that "we cannot hire".
I don't have an English recording of the talk, but I started a series of blog posts about it: http://devteams.at/your_company_will_never_be_agile_intro . I should maybe finish it some day ;)