Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

Re: Software Engineers are a Management Conundrum

swatts
Active Participant

Hello Fellow Programmers,

This article is the product of a lot of years experience and observation, and I'm still trying to get it clear in my head. Which means I'm hoping the conversation will clarify the message.

 

In my nearly 40 years of writing software I've had many people suggest I should change course because of x, y, or z. Currently Large Language Models or AI are going to replace all programmers, previous to that it was off-shoring, previous to that it was RAD (Rapid Application Development systems). I'm guessing the replacement of machine code with high level languages and terminals for punch-cards were similar harbingers of doom. Every advance in productivity is gleefully portrayed as the end of our careers. 

 

And yet here I remain, still making a living, making things...

 

So why is industry so focussed on making us redundant? With very little evidence I believe that programmers are a pain in managements bum. They didn't want to pay my wages, the didn't want to pay for the high cost of career maintenance (training etc), they didn't like that I knew things they didn't, which made a lot of their management levers ineffective. In short I was a problem that needed solving.

 

Here are some of the management "solutions"

 

  • Document code so that a person off the street could replicate it ... Had that suggested a couple of times.
  • Can random person shadow you to learn what you do, called pair-programming now I believe.
  • Use a framework, tool to break a problem in parts so small that the system can be maintained by low skilled operators.
  • Shipping code off-shore chasing the lowest wages.
  • Various processes aimed at removing the skill involved in developing complex systems.

You may think that I'm against all of these, well I'm not, because often they can be a force for good. They are bad when they are implemented by management that doesn't understand you need good people and those good people need rewarding.

 

What if we go the other way? The rockstar programming god is also a problem I've observed. They take advantage of management ignorance to instil fear, source code is hidden and protected. I've fixed a few jobs left by these and it's always hard and management always think their rubbish code is the work of a tormented genius.

 

And here lies the conundrum... 

 

A lot of the tools, processes and methods that make us better engineers can also be used by management to commoditise our work.

 

What is the key to the conundrum?

 

I think it is empathy and focus on delivery. It's a hostile act if all management want to do is reduce your cost or value. It's a similarly hostile act to make something extremely complex so you are the only one who can support it.

 

In the middle is the work, as a programmer delivery is key to a long and happy career. If management concentrate on the ROI of having a great team, rather than just the cost. Outside of just the work, a great team will have so much domain knowledge you can draw upon. Add to this flexibility, support and improvements that would be built in just by leveraging your highly skilled staff.

 

Lots of Love

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Comments
Thoric
Trusted Enthusiast

Beautiful.


 

Thoric (CLA, CLED, CTD and LabVIEW Champion)


SercoSteveB
Active Participant

It has never felt like hostility to me when management implement "solutions", after all part of the management role is to get the largest value for the smallest cost, if I had to pick a word I would go for "misguided" or "misinformed".  

 

My read of the situation is that management have a strong understanding of cost and a weak understanding of value.  As a consequence "solutions" gravitate towards the comfort zone and are cost based, in the same way that engineering solutions tend towards value.  

 

I suspect there is some management/engineering collaborative middle ground somewhere, where value based solutions are allowed to play out and are found to reduce cost (imaging that), unfortunately that is not the world most of us live in.

 

Thought for the day.  I wonder what the world would look like if management was a support service to engineering?

swatts
Active Participant

Very nicely put Steve... I particularly like 

 

"management have a strong understanding of cost and a weak understanding of value"

 

The collaborative middle ground is probably the main point of the article, having a situation that benefits everyone is the most sustainable position and any imbalance creates problems.

 

I loved the idea of having management as a support service to engineering, I'd take it further and say every department should be a support service to every other department, or as a best case scenario... why not have management as part of the team....

 

All this talk of management makes me glad I'm unmanageable.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

richardscheff
Member

I have usually worked in spaces where management has asked what they can do for me, to make my job easier.  There are three things that make the job easier.  Tools /automation, good communication, and acceptance that nothing is perfect from the start.

 

I had a manger ask me if I was worried about AI and would it replace my job.  I told him it just makes it easier to do things like refactor code and make code easier to read.  I have had success feeding in functions into AI for this very need and it does a nice job summarizing code in English, which I do a terrible job at.  Of course it can not read LabVIEW- yet.  

 

While on the topic of AI, it is not a silver bullet. And while it does help generate code faster than me, I still have to go through it and fix mistakes.  I don't think we can ever get away from that.

swatts
Active Participant

And fixing issues is the difficult bit that needs knowledge to do....

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

mbremer
Member

Not sure how much I can add to the conversation, but having transitioned from individual contributor to management then back to individual contributor, the hardest part of management, and the reason why I chose to not do it so much, was the feeling of not being in control. Often there is a good amount, and too often a significant amount, of pressure placed on a manager from higher levels in the business. A good manager is able to take this pressure, shield his team from this pressure (or enough of it), act as bridge between his staff and upper levels, and trust his team.

 

The hardest part for me was not feeling in control of what was being demanded from me and placing that trust in the team. I think this can lead to managers doing things that let them have the feeling of control, whether putting together systems, procedures, frameworks, or something else, they can be used to let the manager feel like they are in control. Like you, Steve, I don't think there is anything wrong with these things; they can be very useful tools if used correctly, but can be twisted to serve the manager rather than the team (e.g. Agile movement gone wrong).

 

In software, I think there are a couple of things that make this worse. I think it's often very hard to demonstrate progress for large periods in a software project, or large progressions don't seem very impressive from the outside without understanding the implications of the work being done. And it also seems like software is one of the last things that needs to be completed in a project (i.e. mechanical and electrical are already in place and software is the glue between it all). This means any slips in schedule are pushed onto the software team. All this leads to greater pressure on the manager, and more reason for them to try to gain control of the situation (even if it's not possible to do or just leads to a greater feeling of control).

 

Anyway, I think the largest thing I took from my foray into management is a greater understanding of the skills required for the job (skills to be a good individual contributor are a lot different from skills needed to be a good manager) and a greater compassion for those that do it, even if I think they're doing it badly!

swatts
Active Participant

You added a lot!

As always the replies are better than the article, this is my only motivation for writing these things.

 

In fact you have succinctly filled in some of the jigsaw for me. I often have a picture for the point I'm trying to make, but not the words. The point of the article is to highlight and verbalise the issues, so that we can recognise them and then hopefully react to them appropriately.

 

I too have sympathy for management, I have been one and didn't like it one little bit. 

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile