Author Topic: Software engineers: managing interference  (Read 1343 times)

Twed

  • Take a Key for Coming in!
Software engineers: managing interference
« on: January 19, 2019, 06:26:01 PM »
Software engineers, do you find a large part of your job involves trying to reject the influence of people who fancy that because they understand some technical concepts, that they are qualified to offer help and nuggets of wisdom that are really just gold Dunning-Krugerrands made of shit?

This is becoming such a large part of my job that I'm beginning to make exit plans.

I can't maintain software after a technical manager has decided that he will "help with small things in the codebase", and can't grasp the concept that "just get it done" code is likely to cause me hours of extra maintenance work for me, or just add bugs to things that will be incredible stressful for me to deal with.

They can't be told. You try, but they don't understand anything beyond "if it works right now it is correct and completed". They will not understand that creating a six-value tuple to store stuff in isn't how it's done, when you can make six variables with names (and just not have complex spaghetti code like that that requires six variables in one place). They don't understand that tweaking core library functions in a way that breaks unit tests just to achieve what they wanted to do in that second is a massive fuckup. Somebody with a future in development might grasp that on the first lesson, but not these eager fucks. They don't understand that adding some API call to a core update loop and not checking return values/exceptions means a future sleepless night and embarrassment for me when it breaks, loglessly, under a certain condition.

I woke up to this on Slack:
"Windows seems to sometimes be reporting positive values and sometimes negative values
-2147483646 vs 2147483646
We might find out that it doesn't work universally, but one option is take the absolute value of the mask when we store the data"

I spent an hour trying to explain that taking the absolute value of a bitmask value changes its meaning, and even if you don't care about the most significant bit right now it's going to be a fucking nightmare in the future when it's implicated in a bug or inconsistency. A fucking hour, and losing by the end of it, just because something they made that interprets that data is taking the value of the entire mask instead of masking out the bits it needs.

I think I will quit.

Consignia

  • Deviant
  • Silver Member
  • ****
  • Just Grand
Re: Software engineers: managing interference
« Reply #1 on: January 19, 2019, 07:31:10 PM »
I'm in a related position were we have an architect who clearly has very little experience with the technologies he's prescribing and is causing an absolute gulf between him and the devs who need to implement them. I don't know how he got to such a prominent position with such a disinterest in the actual implementations but working around his poor choices has been nothing but hassle and has caused several of my colleagues to just quit.

His favoured technology is a graphical ETL technology, which I believe he favours because the implementation matches his diagrams. The problem, it's not easy to write maintainable code for, since it's graphical, so we've had to, at a large effort, write a bespoke methodology for source controlling, deploying and maintaining the application. Such a massive waste just because his choice is immoveable. Devs have politely asked for justifications for the choice and tried to suggest alternatives to only be angrily be rebutted.

For me, our team has been asked to write a new component, and I've tried to make sure we make the best technology choices and only really allow him the highest level overview of what we're doing. Even then I had to rally the entire architect community to my side to get them onside, so they could help persuade him. And even now I'm masking some of the technology choices because I know they are incompatible with his vision, but will make the people on the ground's lives much easier.

In short, it's hard. I just try to engineer the situation to give the blockers as little influence on your work as possible.

Johnny Textface

  • Film grain is a choice.
Re: Software engineers: managing interference
« Reply #2 on: January 19, 2019, 07:38:13 PM »
I do QA so it's all my fault.

Twed

  • Take a Key for Coming in!
Re: Software engineers: managing interference
« Reply #3 on: January 19, 2019, 08:11:52 PM »
I do QA so it's all my fault.
I get on really well with QA! The ask sensible questions, and disconnects usually mean they've spotted something valid that I hadn't seen from their perspective (in what I like to think of as my own idiotic 'idiom' in the same way as Lancelot in Holy Grail) or I teach them something about software and why things work in the way that they do, or we agree on why something needs to work to a compromise or whatever. Always positive.

Sorry to hear about your experience Consignia. It sounds familiar.

In short, it's hard. I just try to engineer the situation to give the blockers as little influence on your work as possible.
Yeah. I'm quite good at this, but there's no winning with an idiot who has power. Son in law of the boss.

I'm going to give it three months, but then I'm scared. I don't want to be dealing with this shit anymore at 35. No part of my brain has slowed down, I've only become better and quicker and sharper at what I do, but by fuck I'm tired of the people, and a combination of that, imposter syndrome, depression and hatred for most of the tech industry has me wondering what the hell I'm going to do.

Paul Calf

  • She's mildly cretinous.
  • Golden Member
  • *****
Re: Software engineers: managing interference
« Reply #4 on: January 20, 2019, 12:20:28 PM »
Do you have a build pipeline with automated unit and integration testing that stops the build on failure?  Do you ban direct commits to master and insist on at least one approval before allowing merge? Do you pair? You should consider it anyway to keep people honest.

Paul Calf

  • She's mildly cretinous.
  • Golden Member
  • *****
Re: Software engineers: managing interference
« Reply #5 on: January 20, 2019, 12:23:54 PM »
ps: I do QA too, but these days I tend to spend more time speccing and writing automated integration and acceptance test suites.

Twed

  • Take a Key for Coming in!
Re: Software engineers: managing interference
« Reply #6 on: January 20, 2019, 04:03:25 PM »
Do you have a build pipeline with automated unit and integration testing that stops the build on failure?
Sure (I'm the one who set it up because nobody else would understand what that even is), but that's not going to stop poor-quality contributions, or a DIY interloper just disabling tests etc. when their stuff doesn't work. The guy has actually modified unit tests to work with their own code, because they're don't get it, and don't have the attention span to be taught.

Do you ban direct commits to master and insist on at least one approval before allowing merge?
Yes, but that's no use when the guy adds himself to the repo with push privileges on master. In this environment, not only are words like "pull request" only meaningful to me, but any attempt to explain them takes incredible energy and is met with crushing dismissal, because they just sound like purist developer things that add meaningless procedure that gets in the way of their goal of doing something quickly and badly.

Do you pair? You should consider it anyway to keep people honest.
That sounds nice! It doesn't apply to my situation, and that's the frustration. We're a small company, I'm the only actual developer. My issue is a guy emboldened with the idea that everybody can have a go at any part of technology. He is very obsessed that idea, won't hire any new staff with experience, and has started a vanity non-profit with the goal in mind of turning landscape gardeners etc. into tech people. He is the boss's son-in-law. I have expended so much energy explaining why we shouldn't do things the way he wants, I have reviewed every commit he's made with him and explained what's wrong, but it falls on deaf ears.

What you're saying is rational and correct, and I'd love for things to work like that. Instead I'm presented with the exhausting zeal of somebody who refuses to cooperate because they've got a complex about being somebody who turns amateurs into his idea of experts*. "We can't let unexperienced developers loose on the codebase" is twisted in his brain to "we need to train the guy who was a mechanic three months ago into being your newest developer". Unassailable.

(You might remember a few months ago how frustrated I was with the brick wall encountered when asking to hire somebody who knew what they were doing. Since then I was let down on a promise to that, and they've hired THREE more "people switching industries and learning the tech ropes" people. It's one of the weirdest obsessions I've ever encountered due to the impact it has. The money thrown around, the lives disrupted... to satisfy ego. Most people in the office are constantly baffled, there are people who just sit at their desks and struggle because there's no resources to train them)

I'm giving it three months (deadline for the first version of the product) and then seeing what the situation is. If it's this, I'm moving on. There's also the chance that he loses interest like he did two years ago when he went through this phase, which would be grand (until it happens again you fool just leave).

* Commendable, but an expert is focused and not a ruinous Jack of all trades

Paul Calf

  • She's mildly cretinous.
  • Golden Member
  • *****
Re: Software engineers: managing interference
« Reply #7 on: January 20, 2019, 04:11:00 PM »
You obviously know your stuff and wouldn’t have much trouble funding alternative employment and, you know, sometimes that really is all you can do. In my 20 years contracting only once have I said to a client “I cannot in all conscience continue to bill you for what I’m doing because what I’m doing is completely counterproductive. Either we sort out the development process between us or I’m going to have to withdraw representation. Up to you.”

I mean, there are times when you give your best advice and the client says “Nope. We’re doing it this way and you just shrug and get on with it and let them pay you to take the long way round but I honestly feared that if I continued to cash their cheques I’d be in breach of contract.

Twed

  • Take a Key for Coming in!
Re: Software engineers: managing interference
« Reply #8 on: January 20, 2019, 04:34:59 PM »
You're right Paul.

The problem is that I get the wrong kind of respect. I'm respected for being good at what I do, I'm treated like a rock star developer (which I hate, as should any reasonable person). But because they don't understand what is needed to architect quality software, my insistence on standard good software practices is ignored. The don't understand what they are, so I think they just consider them peculiarities of a fussy person. This is Infosec, so they have a hacker's mindset. Their view of programming is write-only Python one-liners.

There's also the issue of me being the one actual developer, maintaining the core low-level software, the infrastructure, the API server, the web-based front-end, the database ingestion tools... we all recognise that's too much, but the technical manager I'm having problems with thinks the solution is adding amateurs while I know the solution is hiring professionals.

Some of the people this guy hired as amateurs are even piping up to say "can we stop hiring amateurs". Dismissing that is the sign of a person in a bad state of mind, and that combined with power is a recipe for misery.

Twed

  • Take a Key for Coming in!
Re: Software engineers: managing interference
« Reply #9 on: January 20, 2019, 05:44:45 PM »
I hate this technocratic "teach everybody to code" shit in general. Not in principle, because I want everybody who is interested to be made very welcome and to fuck off with the gatekeepers. But at the risk of sounding like a gatekeeper myself, sending people off to a week at a code camp where they modify the HTML that a Ruby on Rails app generates* and then thrusting them into the world as a developer is good for nobody. It's purely ego-serving. The people who create these initiatives are rarely developers, and don't know what to teach or how to give an accurate idea of what it takes to become a developer.

(With this in mind, I am one-on-one mentoring people via a non-profit that I do respect, and it's going so well. It's so good to discover when people either do or don't come with the software architect mindset, because you can point them to the areas of software or even just technology that they will succeed in)

* When hiring, not just some but most candidates came with this experience

Twed

  • Take a Key for Coming in!
Re: Software engineers: managing interference
« Reply #10 on: January 20, 2019, 05:45:45 PM »
bold text

Consignia

  • Deviant
  • Silver Member
  • ****
  • Just Grand
Re: Software engineers: managing interference
« Reply #11 on: January 20, 2019, 06:13:53 PM »
I don't think it's particularly gatekeeping to want your chosen profession to be, well, professional. We've seen it time and again in the IT industry that hasn't properly valued its people. Remember the massive overseas outsourcing boom of the 00's, where the actual coding was deemed a commodity and you ended up with a massive communications problem because of the distance between the devs and actual users. As a result, you ended up with longer development cycles and poorer quality applications. But hey, the day rate was lower.

I've not really seen the phenomena described of getting people to do those online courses, but I believe it's quite a thing in the US at the moment. I feel that sort of thing is again the higher ups looking at the bottom line and not valuing what a good software engineer needs to be. Indeed, constructing code is just one aspect.

Of course, this all the management view that's the problem. I don't think I'd ever want to discourage anyone who doesn't have a lot of experience, but has enough passion to be self-taught via online courses. Frankly that sort of spark shows more promise than someone who's covered in certifications.

Twed

  • Take a Key for Coming in!
Re: Software engineers: managing interference
« Reply #12 on: January 20, 2019, 06:39:46 PM »
I think it's no coincidence that people who employ software engineers are working hard to make it look like un$killed work.

Twed

  • Take a Key for Coming in!
Re: Software engineers: managing interference
« Reply #13 on: January 20, 2019, 06:49:17 PM »
Of course, this all the management view that's the problem. I don't think I'd ever want to discourage anyone who doesn't have a lot of experience, but has enough passion to be self-taught via online courses. Frankly that sort of spark shows more promise than someone who's covered in certifications.
And self-taught programmers are the best. IMO there's no such thing as a software engineer who is solely college-taught. I don't care if you took Advanced Java, it's not enough, especially when the tools are free to use and you could have put in the practice necessary to make you useful as an entry-level software engineer. And that's what makes it all the more ridiculous that there even needs to be code camps. Maybe if you have to go to a place to tell you to follow a tutorial on how to put together a Ruby on Rails app then you are lacking the most essential skill required in this field - the ability to turn research into code.

The only useful role colleges have in teaching programming is in teaching actual computer science. Algorithms. Software architecture. Stuff that assumes that its students don't need to be told the syntax of the language they're working in, because they have the basic skills to look it up in the abundance of free resources available to them.

I would wager that most computer science graduates don't know who Donald Knuth is.

Guidance? Useful and necessary. Being thrust into templates and producing engineers that can't work without them? Get rid of that.

Zetetic

  • Burying isn't the same as killing.
Re: Software engineers: managing interference
« Reply #14 on: January 20, 2019, 07:09:41 PM »
The only useful role colleges have in teaching programming is in teaching actual computer science. Algorithms. Software architecture.
Nah. Most people who need to know some programming with some confidence to actually use it don't need to know any of this stuff (and where they need to apply, the tools available should better at supporting this). But nor should we be encouraging this as a career, I suppose.

Programming should mostly be being taught in the same sort of thing as "How to manage long documents in Word" and the like. (And it is, by headcount, already. Should still be taught better in that context, of course, but there's a long list of basic skills where that's true.)

(None of that's to deny that there are niches - such as yours - where greater knowledge is required.)

Twed

  • Take a Key for Coming in!
Re: Software engineers: managing interference
« Reply #15 on: January 20, 2019, 07:14:47 PM »
I would refine what you quoted to specifically apply to teaching programming as a profession. It is of course excellent for them to teach programming modules to people who won't focus on it as their main thing. But yeah, you're right. People who can also understand code along with their main profession are valuable and Unis have a responsibility in teaching them the fundamental stuff, so ditching those courses outright would be a bad thing. "Everybody should learn to code as part of their general toolbox" is something I do agree with. My frustration is with them being ushered into software careers with just that.

Paul Calf

  • She's mildly cretinous.
  • Golden Member
  • *****
Re: Software engineers: managing interference
« Reply #16 on: January 20, 2019, 08:12:18 PM »
Oh, god.

Speaking as someone currently working as a test architect, Python (well, specifically Django) is fucking cancer.

Paul Calf

  • She's mildly cretinous.
  • Golden Member
  • *****
Re: Software engineers: managing interference
« Reply #17 on: January 20, 2019, 08:16:26 PM »
I know there are data scientists here who will vehemently disagree with that - and I’m sure you’re completely right to do that - but its ‘killer app’ in the Django framework is just nasty.

Twed

  • Take a Key for Coming in!
Re: Software engineers: managing interference
« Reply #18 on: January 20, 2019, 08:41:05 PM »
It's great, maybe even the best "slightly above scripting level" language. But yeah, an absolute nightmare for large software. The whole point of Python is its straightforward nature, and it's great for software with very few abstractions but falls down when things get large.

buzby

  • Member
  • **
Re: Software engineers: managing interference
« Reply #19 on: January 21, 2019, 08:37:57 AM »
I think I must have a dream job as I'm the only person with login that can access the Clearcase VOBs that hold the code , build scripting and FE Testing suite for the stuff I work on. We also have old-school management who don't want to even see the code, let alone dabble themselves.

Back in the early 80s when there was a shortage of software engineers/programmers the big companies like Plessey and GEC would take on graduates from other disciplines and teach them to be programmers. My old boss had a degree in Zoology and was turned inot a pretty decent programmer (though he ended up retiring when he was put on a project that involved him having ot learn OOA and C++, he was 55 at the time though). A fair few of the engineers in the department had started as electrical or electronic apprentices too, and didn't have degrees.

I'm almost entirey self-taught regarding programming, and have an Electronic Engineering degree. We did one module in the first year about programming concepts in Pascal, but I'd been doing stuff in assembler and C on the C64 and ST for years before that, and did a couple of years of Pascal in my Computer Science A-level. When I started here after university they paired you with a senior engineer as a mentor, and it was the fisrt couple of years working with him (also an EE graduate who did software) that I really learned how to be a professional embedded software engineer. In my first appraisal after getting the job my boss said I was basically an ideal candidate, as the system we worked on was very low level and they almost always found that coders with an EE background understood it better and had a better grasp of designing and writing code to run within the hardware's limitaitons.

Re: Software engineers: managing interference
« Reply #20 on: January 21, 2019, 02:36:41 PM »
I used to have that in my old job where I worked for a large company. Now I work for a very small company where the two or three people I have to interact with know their shit and it isn't a problem

Re: Software engineers: managing interference
« Reply #21 on: January 23, 2019, 11:32:11 PM »
Oh, god.

Speaking as someone currently working as a test architect, Python (well, specifically Django) is fucking cancer.

You'll beg for python when you have to deal with node.js

As Twed said upthread, it has it's place, as a lambda/microservice thing it's brilliant.

Re: Software engineers: managing interference
« Reply #22 on: January 23, 2019, 11:36:06 PM »
I used to have that in my old job where I worked for a large company. Now I work for a very small company where the two or three people I have to interact with know their shit and it isn't a problem

I too have this sort of thing, but also the smaller company is getting bigger and as a developer it seems to be getting worse. I think, unless you want to progress to be a manager or an architect then it's bit like getting on a bus, you've got to know when to get off and on.

Paul Calf

  • She's mildly cretinous.
  • Golden Member
  • *****
Re: Software engineers: managing interference
« Reply #23 on: February 07, 2019, 08:44:05 AM »

Twed

  • Take a Key for Coming in!
Re: Software engineers: managing interference
« Reply #24 on: February 07, 2019, 09:26:32 PM »
Today the helper went through the front end code, messily adding tooltips to every single control. Ones that open automatically and immediately when you hover over the controls. Ones that follow your mouse cursor as it moves around those controls. And not just on controls. Also on every link, button...

Some of the tooltips are paragraphs. Some of them are just added to buttons that are marked "Add <Thing>" and cover up the button when you hover over it to inform you that "Clicking this button with add a <thing>".

Z

  • The movie, not the TV series, or the book
Re: Software engineers: managing interference
« Reply #25 on: February 08, 2019, 02:43:39 AM »
Damn man, this place sounded bad when you wrote about it months ago and this reads like it has only gotten worse.

Why don't you have the power to overrule this technical manager when it comes to hiring choices? Why aren't you quitting?

Twed

  • Take a Key for Coming in!
Re: Software engineers: managing interference
« Reply #26 on: February 08, 2019, 02:45:43 AM »
Because I'm tired, depressed, this at least pays well and I would never be fired. I don't think I have it in me to start somewhere new. I often have Amazons and Googles courting me and I can see Oracle from my window but by fuck I can't do that. I understand that's a problem that comes from inside me and nobody is to blame for that. I often think I'll either have to get really lucky somehow or I'm just over. I think I might be over.

I can overrule, but I don't have the energy to fight all of the time. I just want to build nice things and not have to suffer one person's overbearing insecurities fucking everything up at every place I work. There's always one idiot with too much clout, always. I'm going to become a fishmonger. Fish knows its place. Hah, plaice.

Twed

  • Take a Key for Coming in!
Re: Software engineers: managing interference
« Reply #27 on: February 08, 2019, 02:46:27 AM »
"Clicking this button with add a <thing>".
Typo, "will" not "with". But you get the point.

Twed

  • Take a Key for Coming in!
Re: Software engineers: managing interference
« Reply #28 on: February 08, 2019, 02:55:31 AM »
When I started here after university they paired you with a senior engineer as a mentor, and it was the fisrt couple of years working with him (also an EE graduate who did software) that I really learned how to be a professional embedded software engineer.
The first couple of years! These days the respect for the job is so low that this would be a couple of months. There are too many people, technocrats in particular, who don't understand that being able to write some lines of code does not make a software engineer. People who don't understand what it means to make anything other than big balls of mud.

touchingcloth

  • Member
  • **
  • She is hot in the arse.
Re: Software engineers: managing interference
« Reply #29 on: February 08, 2019, 09:26:10 AM »
What’s wrong with managers dabbbling in the “codebase”? The real problem is that people seem to think the the internet is a giant truck that you can just dump massive quantities of information on, but it isn’t, it’s a series of tubes that can get jammed when people place a massive load into them. My own staff sent me an internet last month but it didn’t arrive until tomorrow because it got tangled up in the tubes.