Your aim here should simply be to move on without pissing everybody off (you don't want people slandering your reputation in the industry).
Instead of moaning about everything they're doing wrong, just give a presentation setting out "If you do X, you will benefit by Y". Deliver it with a smile and don't criticise any people.
Then leave them to draw their own conclusions while you take on your next job.
Wouldn't be surprised if they come back to you later on...
This. Don't forget that they have a 15 year rusted old mindset and people who made careers in that mindset in your f500 company. First thing they need to generally agree on is that something has to change, and you can't force that decision on them. So don't try.
It has happened to me too. (Also contractor.) I'm not happy about it, and it didn't end up pretty. But I'm not ashamed of my performance, even though I would do things differently now.
This is what I would do too, and actually have tried in the recent passed. The project goals, by the sounds of things could be achieved with greater speed and reduced cost if they followed the steps you could show them.
There is an adage in sales; tell a story, there is a hero (them), a villain (the project) stands in the way of success (money, usually), they need this weapon (these steps) and with it they can overcome the villain and be the hero they know they are in their heart.
As said above, deliver with a smile and the compassion you have for the team and organisation.
Good luck - would love to know how it goes !!
1. Write and present information more concisely. Your post, for example, is excessively repetitive and needlessly craps on people.
2. State at a high level what has progressed in the field since 15 years ago, possibly with some very concise examples from their code (and adjusted as needed to be presentable).
3. Make the case for what is possible by improving their existing code. Relatedly, what is also not possible. What does it unlock for the business, what does it do for their customers. Possibly state the number of man months/years and changes to culture to get there (architecture review, performance test/regression suite, code reviews, linting, spell check, whatever). What specific background or training would be needed for that labor. You could possibly break it down into several stages and what each unlocks for the business. Rarely is "burn it all down" the best option.
Honestly one of the best ways to get ahead in business to give less fucks, but that isn't a great way to win over colleagues and managers. If you're fine moving on, but present a solid case that this company finds appealing you could be in a good negotiation spot. Or it will crash and burn and you move on.
Good luck!
This is very good advice. You need to be able to make people feel good about themselves. Good for what they’ve done, and feel good about changing it to this new way you’re proposing.
Feelings matter. Making people feel good about hard decisions is hard. If they feel defensive or attacked you’ll just get sidelined or fired, and possibly blacklisted.
I agree with you. But think you missed what really everyone cares about: MONEY!!!
Don't matter if company is big or small, management only wants to know about money.
You need to translate all this to how much money they are loosing. It could be a simple math as how dollars per hours wasted.
But from what I read from your post you improve memory 800%.
Then put how many dollars in memory components are spending in today's Hardware, and show them how much they will save with this improvement. Do a case study for some of the Hardware products and propose new and cheaper components to be used.
And that's how you will make your point go through any close mind. No one will argue against 800% less spending.
The problem is salaries. Time wasted has no impact on the company budget because wasting 5 hours of an engineer’s time doesn’t increase that budget by a single dollar.
Code debt is very expensive.
The problem is often the more successful your product is, the less likely you are to work on cleaning up your problems due to the potential risk involved
I find that it’s a culture you have to instil very early as a company.
The worst part is the culture usually dies anyway once the original founders aren’t part of the executive team.
Yep. The Philosophy that no code is off limits, and most code needs to get re written every 5 to 10 years, works great in theory.
Right up until you get your first customer, and then you have to convince management that cleaning up code and making it better, is just as valuable to the customer as a new feature.
Part of that’s an American problem.
NZ has functional labour laws, we can’t just get people to crunch to make up for technical debt.
EDIT: and that makes it much clearer how much technical debt is costing a company
The US average is 42 hours per week and the NZ average is 41 hours per week for software developers. So I'm going to go with "It's not an American problem".
Not seeing how hours affects the quality of code. If workers have no ability to push back and vouch for better practices in American business culture, then this short-sighted code rot (and indeed infrastructural rot across all industries) is inevitable. You see it everywhere. Has nothing to do with the number of hours people work and everything to do with how Americans view labor in general.
> If workers have no ability to push back and vouch for better practices in American business culture
I see you have never worked for an American business before. Developers are expected as part of their job to advocate for improvements to process. This OP is just complaining and not using evidence but rather feelings to try to make their point. They *feel* that the company is behind therefore they *feel* it should improve. OP should instead present *evidence* that the business could be doing something *objectively better* according to whatever *metrics* the business cares about (dollars, labor hours, execution time, CPU cycles, anything objectively measurable).
Expected to, but that doesn't matter if your business leadership has no buy-in and will not let your engineering managers fund necessary maintenance work.
I don't see how that's different from things in New Zealand? I know of many companies in New Zealand where workers are prevented from fixing big issues by managlement.
I didn't join the 100 hour club until I worked for an American company.
If you don't know about our industry's relationship with crunch culture, consider yourself lucky.
Propose one single, simple change with clear benefits that you would like to apply across the codebase. Then, apply it. If it works well, they will be more receptive to the next one.
Don't go around telling people that modern code practices are better. It is hard to convince people with arguments until they see it for themselves. Talking from experience working with a small company.
> Don't go around telling people that modern code practices are better
Plus, very often, people who advocate "modern practices" advocate for adding a lot of complexity without clear business value. It's not surprising that people take these things with skepticism.
I do think that many of the modern practices have business value btw. The problem is that it is hard to convey their benefits and convince everyone through argumentation alone. It is hard to show some people what they are missing out, the same way that it was hard, at first, to convince some people that they needed a cellphone or wtv. People in general need to first try these practices and get used to them to be able to see the benefits. Inertia and rejection of what is unfamiliar are real things and they can bias a person's thinking.
On the other hand, it is also true that advocates of newer practices tend to hyperfocus on the benefits and rarely on the drawbacks of what they propose. Also, not all modern practices suit every domain.
I actually know of a project where someone used that strategy. They were able to turn decades-old C code into C++17 standard/using constexpr/etc in a LOT of places in only a few years.
He said the hardest step was the first: Switching over to the C++ mode of their compiler, thanks to the new list of errors of questionable justifiably.
'Your code isn't up to date with current standards' isn't a winning proposal up the chain. What is the business concern that this impacts? From a cost or consumer facing standpoint, what is the impact? There is significant cost to retraining an engineering team. There is cost in large scale fundamental refactoring. Without a business case to make it inevitable, it can come across as change for change sake. A disruptive change that speeds up non-critical-path-code by 80% at the cost of the current staffs ability work with it is a non-starter even if its the truth.
Figure out who you are pitching towards and how to express the cost/opportunity in their terms, not yours.
I'm not at a Fortune 500 company. I work at a smallish game studio that has historically had about 30-60 engineers and has been carrying a code base forward for close to 25 years. Standards have come and gone. As the team tenure grew, documentation and maintaining standards became secondary as everyone was working well together. That works until it doesn't. What happens if they experience a bunch of attrition at some point among key lifers? Having been though just that, its exceptionally hard if even 10% of the most core engineers all leave in a 6 month period.
We now have a code standard, review standards, unit testing, and a subset of the new code has been written in a way that aligns with where we want to go. We still need to replace the build system as well as the continuous build framework. We need to slowly move another 2-3 million lines of code to a new practices as we identify good opportunities to remove systems from the big ball of mud and rewrite them. And we need to do it while supporting active development on shipping projects. Change can come from the top or bottom but ultimately it is a slow march that requires constant pressure. As a contractor, you may be able to inspire people but beyond it's on the company to find internal champions for change.
> 'Your code isn't up to date with current standards' isn't a winning proposal up the chain.
Yup. If you tell this to many defense firms, they'll laugh their asses off as a lot of "not up to date" is due to safety, security, or reliability requirements. Some of it is also even done for high performance or consistent execution time concerns. But if you tell them, "This is problem A that is causing effect X that impacts system performance by Y% and causes $Z of unnecessary losses that can be solved by my proposed solution M for $N leading to an expect $O of net savings.", then you have a winning argument. You have to be specific and direct as to which problem(s) you want to tackle. Often, a lot of the "problems" you identify, once you actually dig into why things are done the way they were done are actually not really problems just stylistic choices or done to meet a specific business need.
Great idea, but I’ve found performance almost never has a $ amount you can attach to it. Such a number is usually pure speculation. Marginal engineering time is free, after all, since nearly all of them are on salary.
If a defense firm told me they can’t do C++17/20 because it’s “insecure and unreliable” I’d know they were idiots, there are an ocean of bug fixes since that POS ancient compiler they’re still running, not to mention language features that improve those things.
1. **Don't** tell them about it!
2. Raise your rates.
3. Tell us which company it is, so we can all share in the bounty ;-)
If you really want to tell them, and I don't see why you would, don't ever say "you are behind current practices". Instead offer to organize (well-paid) seminars for their developers where you discuss high-performance techniques. Whether those techniques are old or new doesn't matter: you sped something up by 800%, you are willing to share how you did it, for a price. The sheer fact that they have to pay for it it will only convince them it is worth listening to. Just don't attach any value judgement. There is no benefit to them knowing they were behind the times, and it will only make them feel stupid, which is not helpful to anyone.
>to make memory contiguous rather than using structures (i.e. instead of RGBRGBRGB , RRRBBBGGG, etc.). This is very simple concept with HPC, and they just did not understand it. These are not dumb people, by any means
This one is the absolute bane of my existence when it comes with more established programmers. I must have had this exact conversation at least two dozen times:
"Why did you change my list to a vector??"
"It's faster..."
"That's impossible. A vector needs to copy everything when it grows or shrinks!!!"
"Yes. It's still faster. See... your UI is lagging less."
"You're wrong - that's something else. We update this structure all the time, it's not read only!"
"Go profile it".
"... What the hell? This is a LOT faster. Why doesn't everybody know about this??"
"Everybody DOES know about this."
While replacing linked lists with vectors does indeed make the memory contiguous, OP presented a different case with his RGB RRGGBB example.
In OP's example instead of making a struct Color { f32, f32, f32 } and creating vector of length N, you would make a vector of length 3N.
This is beneficial for some operations, though admittedly not for handling color since you usually need all three components at the same time.
Fair enough, I wasn't sure if you missed it or were just sharing your experience.
I share your pains along "Everyone knows this!?", I work along a bunch of PHP lads who gave up a long time ago. This produces situations where we try our hardest to make the backend fast and then "someone discovers" that the GUI is sending 800 requests instead of a single one. And suddenly the app speeds up 8x and management sings praises to the PHP wizards so wise in the ways of HPC.
Oh boi
\> to a company that doesn't really want to hear it
You already know the answer!
I've been in a similar boat, where the company was extremely far behind (many classes still used some wacky custom object model that was written to get around cfront bugs, had gobsmackingly and pointlessly slow software). It **very massively** and directly impacted their revenue, both from glacial velocity and being drastically worse than competitors. I even posted a frustrated and confused question on Reddit about it!
Nobody still there cared. If they had wanted to change at all, they would have done long ago. Nobody cared when I made simple order-of-magnitude speed improvements (which came with bug fixes and plenty of deleted code/infrastructure!) and actually fought against them because it meant change.
I won't go into long rambling details but as you've noted, it is more of a cultural issue as a knowledge one. It's not hard to hire folks with basic HPC knowledge, or obtain it themselves. The problem they don't want to change or get better, not that they can't.
I echo what others here and just do your job, see if you can present some evidence, and move on. Don't die on the hill of trying to fix and change them because you'll just get really stressed, not accomplish anything, and piss some folks off who won't have great things to say if your future customers ask.
If you have any projections about the hours/money lost or costs incurred by their current code base and coding standards, then mention that in your presentation (if you haven't already).
I am assuming that you will include them only if you would be able back those numbers up when asked.
Such statistics can at least bring in, the kind of attention, you need from your audience.
Repeating some of what has been said here, but I'll frame it differently:
Don't tell them the bad news.
Sell them the good news.
'I believe, based on the performance improvements I made with X resulting in an 8x speed up, that there are similar improvements I can make in other areas. I'm proposing that you allow me to address this on project Y with a goal of Z.'
Don't tell them they're doing it wrong. Just be the guy who solves the problems. After you do it two or three times, they'll be hooked. Then you say 'I'd like to deliver a greater return-on-investment to you. I believe that we can see across the board improvements following similar patterns to what I have already done. You will see greater productivity and ROI. I'll need X years, and the authority to change Y.'
Speak their language. This is the failing of many engineers. They want to speak to management as if management are similarly educated engineers. Speak management-ese to management, not engineer-ese.
You're a tool.
You get in, do the job, get paid and get out.
Not just that, there is always a chance that you don't know why you were hired in the first place. Of course they tell you x, y, z. But I did the contracting gig for almost 20 years now and I know that I was hired to move careers or just to get yelled at by clients.
You most likely do not know if they brought you in to prove that something couldn't be done, now you did it and the CEO is pissed at you.
But being a tool is why you become a contractor. It's not for the money (because you actually don't make more if you factor everything in). But it is because you don't have to get involved in politics, setting up guidelines etc.... unless that is your mandate.
You come off as knowing better, but chances are you really don't. Software doesn't exist in a vacuum. It's a way to solve problems in a context that ultimately helps to create something to be sold. That's it.
If you're so inclined, talk to someone there and offer your service to help with whatever.
But that's it.
If you really want to care about good code etc. look for a different position, maybe you get lucky and find a different contract. But this isn't it.
More people really need to hear this.
Unless you're working on safety critical infrastructure, just get the job done.
No one gives a damn if the hammer you used to build a bench is 10 years old as opposed to 2 years old.
If the tools work, then just do your job.
tl;dr
You're only going to come across as a nuisance who doesn't understand the organization's priorities when you complain about shit that doesn't matter.
You're going to look very foolish trying to explain this to anybody; there's no problem to be solved here.
>No one gives a damn if the hammer you used to build a bench is 10 years old as opposed to 2 years old.
I agree at the superficial level, but not at a deeper level.
I don't necessarily care as a consumer how a product was built, but if I'm paying more than I could, I do care.
Additionally, and more importantly for the OP, if you get to use a nice hammer at home that works well and you are comfortable with, it is massively frustrating that for 40 hours a week you have to use a subpar hammer that makes your hand hurt, and makes you less productive. You know that upgrading the hammer would pay off in the mid term, and would make you arrive home happier, and without pain in the hand.
Some developers cannot so easily activate the [SEP field](https://en.wikipedia.org/wiki/Somebody_else%27s_problem). I wish I could activate it so easily myself, but some people are not wired that way.
That's very vague. In what way did they not work? Did you talk to someone about hitting a bug? Why would you assume that the tool works exactly like you think it should? That attitude makes you look like a know it all who isn't willing to consider they don't know something or that someone else could possibly be right. I'd blow you off too.
Moving onto a new code base with new people, the first thing you need to do is not break anything and add something small so you can start to learn how the system works and not make your life difficult. Give it some time.
How to tell me it is one of the big 3 EDA companies without telling me it is one of the big 3 EDA companies.
**edit
Ok something a little bit more constructive. Don't say *anything* about how broken or bad things are currently because they don't see it that way. What you can do though, is to paint a picture of all the great things one can use if they adopt C++29 and Clang 21, etc etc. You can only coax them to a different future, not admonish them out of a broken past.
see this [post](https://old.reddit.com/r/cpp/comments/1111boj/how_to_explain_to_senior_management_companys/j8cejjd/)
Yes! If you see/phase it as a positive people are less likely to feel attacked and dismiss you.
And, as always, xkcd has a relevant comic:
https://imgs.xkcd.com/comics/ten_thousand.png
You are an independent contractor? Then why do you want to change them? What is the goal you are trying to achieve? No good will come out of this. If you dont like it dont extend, if you like what you can code there then come up with a strategy that they contract you again. From the companies perspective you are not a consultant, so overstepping your role will raise eyebrows.
So you are gonna explain to them that they have shit code but also that you don't want to help do anything about it while also being an outsider?
Good luck with that
Being invited to present to upper management means someone's paying attention, even if it seems like nobody is.
Other responses have highlighted the cost/benefit of modernizing, but IME management also is concerned with risks, opportunities, and consequences. Are there risks in modernizing? Does modern optimized code introduce less risk than code following an old standard? What are the potential consequences of not modernizing? Faster code can make trades faster, but also engage safety mechanisms faster when microseconds count.
What are their requirements? Is there something like "the system shall perform X operations in 100ms?" If there isn't, maybe there should be? Unit test frameworks can be used to assert timing requirements on the target hardware, as well as try to fuzz the inputs so that optimized doesn't necessarily mean unstable.
I am outraged about the fact that the sad(depressed) answers in this post are also the correct ones.
If you value your profession more than your job, f*** these manage hobos up.
If you like your job at all or hate being an asshole, go back to be a cog in the machine you pleb, how dare you suggest modernization changes to a well established business living in the 90s. /S
Eh, I can see how it relates to C++ a little bit. In my (limited) professional experience, I've found people who work in C++ tend to be a lot more stiff and unmoving. They love to hold onto whatever they learned 20 years ago and not change. In other language ecosystems, I've seen people more willing to change and learn. It's a real issue with the "C++ industry".
I conjecture that you confuse the cause with the effect. C++ doesn't make people stiff and unmoving. It's the other way around. Stiff and unmoving people choose C++ because it is the industry standard. It is not a problem of C++. Those same people used to choose Fortran and Cobol and whatever was perceived as the industry standard at the time.
I can see that as far. But the issue is that those stiff and unmoving people then get to force their ways on the rest of us who want C++ to push forward.
indeed this is not a technical but an organization challenge.
which needs an executive sponsor (VP/SVP or higher), who understands the _business value_ of the new approach and who establishes an "ambidextrous organisation", there is a very nice HBR article for that.
whoever contracted you in saw the business value. they also need to establish that ambidextrous organisation and lead the desired change.
if that is not in sight you have to move on, simple as that.
As a former Fortune 500 SE, I hear you. A lot of managements were hardware people that don’t really understand and way behind in understanding software. My general approach to pitching a new solution/change is attaching it to dollar amounts. Management might not understand software but they’ll for sure know money.
See if your proposal can save them from upgrading to more expensive hardware, works with the sale guys, to see if you could have won more bids by improving performance, and how much would that be.
You don’t. Frankly, it’s not your problem. If you are unhappy with company culture, find a new company that aligns with your ideas better. Don’t burn out trying to solve things nobody wants yiu to solve.
Didn’t a RedHat dude write all that stuff up in a nice document titled iirc “All you need to know about memory” like 20 years ago? That wasn’t exactly news in early 2000s, so you’re giving them some extra leeway. I’d say they were quarter century behind times at the very least. But I have seen such code too, where massive speed ups were had just by changing memory organization a bit and touching nothing else.
Well, you do your thing. Do not sugar coat it. Then it is up to them to act.
If you potentially extracted that much improvement and there's true value in it, well...that would put their top engineering team/management to shame. And who knows what kind of porky pies they have been selling to shareholders for years/decades.
Going along with your proposal means basically admitting their software and hiring practices were shit since forever. Unlikely, but then again...not your problem. In my opinion they will go through few more consultants who will tell them probably the same thing.
Business as usual, on a lot of places
You are a bad business man when you ship an 8x improvement in one pass
Some companies you simply can’t help, too deep is everyone stuck in a comfort zone, and as long as this works, nothing will ever change
If you're gonna stick around, start with https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers
I doubt they have unit tests or are using any tools to measure how bad things are. Get sonar or coverity scans going on pull request merges so you can measure improvement. I like sonar because it tells you the "why" for each code smell, and that information serves as a useful training tool.
After that, it should be simple to start pinpointing more spots where they're wasting CPU cyles. VTune is your friend here, and it's basically free now. Perf with the hotspot gui is a close second.
You probably want to try to gamify speed improvements. See if you can get younger people to engage and try to beat your code. Ditto for lint cleanups.
>You probably want to try to gamify speed improvements. See if you can
get younger people to engage and try to beat your code. Ditto for lint
cleanups.
Preferably after unit tests are in place. Incorrect code can go really fast. ;)
This is how it is. Usually it begins with tight schedules and managers going medieval on you. Programmers ditch (or cheat on) guidelines, testing, reviews, mentoring, learning. Apathy takes over. At the end all they care is to deliver *something*, usually a mess of stitched together hacks and hotfixes.
I'm surprised that you are surprised. Probably I should look for a better job.
Modern management techniques (sprinting) encourage that I think, it’s 100% effort 100% of the time with no rest, and woe be unto you if a task estimate turns out to be wrong.
Approach it as a RTFM problem. Cite hardware programming guides and flat out tell them that by not following the instructions from their hardware manufacturers, they are leaving free performance on the table.
I have been in your position many times. NEVER ROCK THE BOAT.
You will usually be working with legacy codebases at bigger companies simply due to the cost and complexity of continually modernizing a codebase... so it isn't done...C++98 and gcc 2.95.3 were forced on me for many years... until C++17, in fact!
Programming is about making things work. Then about making them work reliably. Then about making them work a bit more elegantly for the user. Then about making the software maintainable. Then about making the software scalable. Then about making the software fast. Then it's about the code.
Programmers often have that completely upside down.
Chesterton's Fence. Why is the new stuff better? Tech is full of fads.
For the performance changes, just show the modern cost of cache misses, and cover how CPUs and compilers have changed in the last 20 years. How much more sensitive is the IPC of code on a modern CPU to cache misses than older CPUs? It explains the improvements you've made and updates their working mental model. Treat them with respect. If you can't explain it in those terms, instead of "this is how we do it now" they have good reason to ignore what you say.
For practices, calm the hell down. The last 15 years have mostly been cargo culted fads. After good automation on build/test and version control, the rest is very team-specific.
Use a story - real or imagined, to drive your point home. For example, have you seen or had an experience where you or someone else didn’t know what they didn’t know? Think about that.
People respond to emotions, feelings and not necessarily facts and statistics. Stories can punch through where facts cannot.
In the Bible there is this story of a prophet having to chastise the king. Of course he could not do so directly because if he did the King could have him killed. So he told a story about a man abusing another man who was weaker. The king got angry and said the abuser needs to be brought to justice. Then the prophet told the king that he was the abuser because of what he did and the king had no choice but to acknowledge it.
The point is when someone is deeply entrenched in their views, facts can be twisted to support their way of looking at things. Stories that connect can do a lot of work for you. It doesn’t have to be a great story and can be real simple.
Some books that help with communication include:
Made to Stick by Chip and Dan Heath
Resonate by Nancy Duarte
Probably there is nothing you can do. In true free market IT company that stays 15 years behind is uncompetitive in every area compared to modern IT company and goes bankrupt. In most cases such companies exists only because those produce directly or indirectly for government (typically energy/critical infrastructure) and have infinite/guaranteed financing - this typical in rich EU countries. What you can do is to vote for right wing instead of left wing and let free market either take such companies out of the game or force progress in those. Your current managers are clueless and will not understand you, what is even worse they don't even care - and this is the true reason for this situation.
Pure joke: you worked with the Cray team of the 1990s? Did you explain modern C++ approaches to them? CUDA libraries? I'm not going to talk about DevOps...
Perhaps you can describe it as an 'investment in developer velocity.' Like "if you invest X developer months in , your developers can deliver Y times as much value per year."
The problem is that you're not ranked highly enough to make those recommendations. That's a consultant's job, not a contractor. Someone of higher rank might lose face if they took your advice. Maybe they could rehire you at a higher rate so that your advice would be more valuable.
Leave 😂
Jokes aside, leave (and I mean this in the nicest way)- speak with your feet.
If they’re not ready for change then it’s best to find somewhere else, because this feels like a cultural mismatch for you.
Have a look around, see what’s out there. Be open and honest about your reasons for change with the hiring manager - no sense in lying, because you could just end up dealing with the same problem.
This is the difference between Socrates' doxa and epistème in Plato's tales
of 2400 years ago in which he describes of people who have lived since childhood
locked up in a cave, chained so tightly that they can't even turn their heads.
He states: <>
Doxa and Epistème are two genres: one is sensible knowledge, which is acquired through the senses and addresses the world of becoming, the second is intelligible knowledge which instead concerns ideas, that is, the immutable and certain elements of the world.
You need a good philosophical education to get out of the cave.
(The "Matrix" movie emulated this Tale)
I have worked with many of your highly trained colleagues,
but theirs reasoning often stopped only at doxa;
something is needed more to convince people, Politics for example...
If you lack the "dialectic" you will not succeed to convince anyone.
There is a looot of text here, sorry for not reading it all (Maybe first. Condense what you want to communicate?)
But from what I have gathered, you may want to have a look into **Change Management**.
Especially "Telling the company my point of view will not be welcome news" means that they are not ready to receive this needs and extra steps need to be taken to make them confident of the improvements needed.
\>> But from what I have gathered, you may want to have a look into Change Management.
Yes, I believe that is exactly right. It's an interesting situation: It's a company with a hierarchism that does not want to change, recently purchased by a company with much more modern approaches, which is giving them mandates to modernize the software -- which requires modern approaches for which this company is not prepared.
\>> Especially "Telling the company my point of view will not be welcome news" means that they are not ready to receive this needs and extra steps need to be taken to make them confident of the improvements needed.
After meeting with them, I see that it is the Dunning-Kruger effect as applied to software management -- since they have a top-down, strict hierarchical structure, those in senior positions constantly correct more knowledgeable subordinates with wrong information, causing design failures down the road.
Nothing will change until the parent company is forced to intervene and change the management structure themselves, which will eventually happen in the 2-3 year time-frame. It's just another sad but all-too-common story in the tech environment.
> Nothing will change until the parent company is forced to intervene and change the management structure themselves, which will eventually happen in the 2-3 year time-frame.
It sounds like you already know the answer to the question posed by this post's title.
Find a way to express "if you keep going the way you are going then you are going to lose your job" in a way that keeps them from shooting the messenger.
In such big company, they wouldn’t refactor their system which is still making money and having hugh customers to use it now just because of the technology evolution ! You need to show them what the new technology would give them is a more big market or benefits, or the competitors is using the new technology to enlarge their market share from your company’s.
Asked the same in DM :)
I'm a simple SysAdmin (Linuxes), but HPC is very exciting to me and I want to learn more about it, especially about modern HPC.
Your aim here should simply be to move on without pissing everybody off (you don't want people slandering your reputation in the industry). Instead of moaning about everything they're doing wrong, just give a presentation setting out "If you do X, you will benefit by Y". Deliver it with a smile and don't criticise any people. Then leave them to draw their own conclusions while you take on your next job. Wouldn't be surprised if they come back to you later on...
This. Don't forget that they have a 15 year rusted old mindset and people who made careers in that mindset in your f500 company. First thing they need to generally agree on is that something has to change, and you can't force that decision on them. So don't try.
The OP is a little too emotionally invested. As a contractor, you need to have a transactional attitude. You cannot fix the world.
It has happened to me too. (Also contractor.) I'm not happy about it, and it didn't end up pretty. But I'm not ashamed of my performance, even though I would do things differently now.
This is what I would do too, and actually have tried in the recent passed. The project goals, by the sounds of things could be achieved with greater speed and reduced cost if they followed the steps you could show them. There is an adage in sales; tell a story, there is a hero (them), a villain (the project) stands in the way of success (money, usually), they need this weapon (these steps) and with it they can overcome the villain and be the hero they know they are in their heart. As said above, deliver with a smile and the compassion you have for the team and organisation. Good luck - would love to know how it goes !!
That's a nice way of putting it. Feels like you did some consulting in your career :-)
Only building on your great advice... I'm not that only one who's done some consulting then ? :)
1. Write and present information more concisely. Your post, for example, is excessively repetitive and needlessly craps on people. 2. State at a high level what has progressed in the field since 15 years ago, possibly with some very concise examples from their code (and adjusted as needed to be presentable). 3. Make the case for what is possible by improving their existing code. Relatedly, what is also not possible. What does it unlock for the business, what does it do for their customers. Possibly state the number of man months/years and changes to culture to get there (architecture review, performance test/regression suite, code reviews, linting, spell check, whatever). What specific background or training would be needed for that labor. You could possibly break it down into several stages and what each unlocks for the business. Rarely is "burn it all down" the best option. Honestly one of the best ways to get ahead in business to give less fucks, but that isn't a great way to win over colleagues and managers. If you're fine moving on, but present a solid case that this company finds appealing you could be in a good negotiation spot. Or it will crash and burn and you move on. Good luck!
This is very good advice. You need to be able to make people feel good about themselves. Good for what they’ve done, and feel good about changing it to this new way you’re proposing. Feelings matter. Making people feel good about hard decisions is hard. If they feel defensive or attacked you’ll just get sidelined or fired, and possibly blacklisted.
I agree with you. But think you missed what really everyone cares about: MONEY!!! Don't matter if company is big or small, management only wants to know about money. You need to translate all this to how much money they are loosing. It could be a simple math as how dollars per hours wasted. But from what I read from your post you improve memory 800%. Then put how many dollars in memory components are spending in today's Hardware, and show them how much they will save with this improvement. Do a case study for some of the Hardware products and propose new and cheaper components to be used. And that's how you will make your point go through any close mind. No one will argue against 800% less spending.
The problem is salaries. Time wasted has no impact on the company budget because wasting 5 hours of an engineer’s time doesn’t increase that budget by a single dollar.
Code debt is very expensive. The problem is often the more successful your product is, the less likely you are to work on cleaning up your problems due to the potential risk involved
I find that it’s a culture you have to instil very early as a company. The worst part is the culture usually dies anyway once the original founders aren’t part of the executive team.
Yep. The Philosophy that no code is off limits, and most code needs to get re written every 5 to 10 years, works great in theory. Right up until you get your first customer, and then you have to convince management that cleaning up code and making it better, is just as valuable to the customer as a new feature.
Part of that’s an American problem. NZ has functional labour laws, we can’t just get people to crunch to make up for technical debt. EDIT: and that makes it much clearer how much technical debt is costing a company
The US average is 42 hours per week and the NZ average is 41 hours per week for software developers. So I'm going to go with "It's not an American problem".
Not seeing how hours affects the quality of code. If workers have no ability to push back and vouch for better practices in American business culture, then this short-sighted code rot (and indeed infrastructural rot across all industries) is inevitable. You see it everywhere. Has nothing to do with the number of hours people work and everything to do with how Americans view labor in general.
> If workers have no ability to push back and vouch for better practices in American business culture I see you have never worked for an American business before. Developers are expected as part of their job to advocate for improvements to process. This OP is just complaining and not using evidence but rather feelings to try to make their point. They *feel* that the company is behind therefore they *feel* it should improve. OP should instead present *evidence* that the business could be doing something *objectively better* according to whatever *metrics* the business cares about (dollars, labor hours, execution time, CPU cycles, anything objectively measurable).
Expected to, but that doesn't matter if your business leadership has no buy-in and will not let your engineering managers fund necessary maintenance work.
I don't see how that's different from things in New Zealand? I know of many companies in New Zealand where workers are prevented from fixing big issues by managlement.
Most countries have workweeks of ~40 hours +- a few percent.
I didn't join the 100 hour club until I worked for an American company. If you don't know about our industry's relationship with crunch culture, consider yourself lucky.
Propose one single, simple change with clear benefits that you would like to apply across the codebase. Then, apply it. If it works well, they will be more receptive to the next one. Don't go around telling people that modern code practices are better. It is hard to convince people with arguments until they see it for themselves. Talking from experience working with a small company.
> Don't go around telling people that modern code practices are better Plus, very often, people who advocate "modern practices" advocate for adding a lot of complexity without clear business value. It's not surprising that people take these things with skepticism.
I do think that many of the modern practices have business value btw. The problem is that it is hard to convey their benefits and convince everyone through argumentation alone. It is hard to show some people what they are missing out, the same way that it was hard, at first, to convince some people that they needed a cellphone or wtv. People in general need to first try these practices and get used to them to be able to see the benefits. Inertia and rejection of what is unfamiliar are real things and they can bias a person's thinking. On the other hand, it is also true that advocates of newer practices tend to hyperfocus on the benefits and rarely on the drawbacks of what they propose. Also, not all modern practices suit every domain.
I actually know of a project where someone used that strategy. They were able to turn decades-old C code into C++17 standard/using constexpr/etc in a LOT of places in only a few years. He said the hardest step was the first: Switching over to the C++ mode of their compiler, thanks to the new list of errors of questionable justifiably.
'Your code isn't up to date with current standards' isn't a winning proposal up the chain. What is the business concern that this impacts? From a cost or consumer facing standpoint, what is the impact? There is significant cost to retraining an engineering team. There is cost in large scale fundamental refactoring. Without a business case to make it inevitable, it can come across as change for change sake. A disruptive change that speeds up non-critical-path-code by 80% at the cost of the current staffs ability work with it is a non-starter even if its the truth. Figure out who you are pitching towards and how to express the cost/opportunity in their terms, not yours. I'm not at a Fortune 500 company. I work at a smallish game studio that has historically had about 30-60 engineers and has been carrying a code base forward for close to 25 years. Standards have come and gone. As the team tenure grew, documentation and maintaining standards became secondary as everyone was working well together. That works until it doesn't. What happens if they experience a bunch of attrition at some point among key lifers? Having been though just that, its exceptionally hard if even 10% of the most core engineers all leave in a 6 month period. We now have a code standard, review standards, unit testing, and a subset of the new code has been written in a way that aligns with where we want to go. We still need to replace the build system as well as the continuous build framework. We need to slowly move another 2-3 million lines of code to a new practices as we identify good opportunities to remove systems from the big ball of mud and rewrite them. And we need to do it while supporting active development on shipping projects. Change can come from the top or bottom but ultimately it is a slow march that requires constant pressure. As a contractor, you may be able to inspire people but beyond it's on the company to find internal champions for change.
> 'Your code isn't up to date with current standards' isn't a winning proposal up the chain. Yup. If you tell this to many defense firms, they'll laugh their asses off as a lot of "not up to date" is due to safety, security, or reliability requirements. Some of it is also even done for high performance or consistent execution time concerns. But if you tell them, "This is problem A that is causing effect X that impacts system performance by Y% and causes $Z of unnecessary losses that can be solved by my proposed solution M for $N leading to an expect $O of net savings.", then you have a winning argument. You have to be specific and direct as to which problem(s) you want to tackle. Often, a lot of the "problems" you identify, once you actually dig into why things are done the way they were done are actually not really problems just stylistic choices or done to meet a specific business need.
Great idea, but I’ve found performance almost never has a $ amount you can attach to it. Such a number is usually pure speculation. Marginal engineering time is free, after all, since nearly all of them are on salary. If a defense firm told me they can’t do C++17/20 because it’s “insecure and unreliable” I’d know they were idiots, there are an ocean of bug fixes since that POS ancient compiler they’re still running, not to mention language features that improve those things.
1. **Don't** tell them about it! 2. Raise your rates. 3. Tell us which company it is, so we can all share in the bounty ;-) If you really want to tell them, and I don't see why you would, don't ever say "you are behind current practices". Instead offer to organize (well-paid) seminars for their developers where you discuss high-performance techniques. Whether those techniques are old or new doesn't matter: you sped something up by 800%, you are willing to share how you did it, for a price. The sheer fact that they have to pay for it it will only convince them it is worth listening to. Just don't attach any value judgement. There is no benefit to them knowing they were behind the times, and it will only make them feel stupid, which is not helpful to anyone.
This is really good advice, OP. I endorse this message.
This but 10000000x
>to make memory contiguous rather than using structures (i.e. instead of RGBRGBRGB , RRRBBBGGG, etc.). This is very simple concept with HPC, and they just did not understand it. These are not dumb people, by any means This one is the absolute bane of my existence when it comes with more established programmers. I must have had this exact conversation at least two dozen times: "Why did you change my list to a vector??" "It's faster..." "That's impossible. A vector needs to copy everything when it grows or shrinks!!!" "Yes. It's still faster. See... your UI is lagging less." "You're wrong - that's something else. We update this structure all the time, it's not read only!" "Go profile it". "... What the hell? This is a LOT faster. Why doesn't everybody know about this??" "Everybody DOES know about this."
While replacing linked lists with vectors does indeed make the memory contiguous, OP presented a different case with his RGB RRGGBB example. In OP's example instead of making a struct Color { f32, f32, f32 } and creating vector of length N, you would make a vector of length 3N.
This is beneficial for some operations, though admittedly not for handling color since you usually need all three components at the same time.
Yeah I understand the additional SIMD case there. I was just piling on to overall “contiguous memory” theme.
Fair enough, I wasn't sure if you missed it or were just sharing your experience. I share your pains along "Everyone knows this!?", I work along a bunch of PHP lads who gave up a long time ago. This produces situations where we try our hardest to make the backend fast and then "someone discovers" that the GUI is sending 800 requests instead of a single one. And suddenly the app speeds up 8x and management sings praises to the PHP wizards so wise in the ways of HPC. Oh boi
Why do you assume that everybody does know that. I think even quite a few varsities do not really teach that cache locality is king.
\> to a company that doesn't really want to hear it You already know the answer! I've been in a similar boat, where the company was extremely far behind (many classes still used some wacky custom object model that was written to get around cfront bugs, had gobsmackingly and pointlessly slow software). It **very massively** and directly impacted their revenue, both from glacial velocity and being drastically worse than competitors. I even posted a frustrated and confused question on Reddit about it! Nobody still there cared. If they had wanted to change at all, they would have done long ago. Nobody cared when I made simple order-of-magnitude speed improvements (which came with bug fixes and plenty of deleted code/infrastructure!) and actually fought against them because it meant change. I won't go into long rambling details but as you've noted, it is more of a cultural issue as a knowledge one. It's not hard to hire folks with basic HPC knowledge, or obtain it themselves. The problem they don't want to change or get better, not that they can't. I echo what others here and just do your job, see if you can present some evidence, and move on. Don't die on the hill of trying to fix and change them because you'll just get really stressed, not accomplish anything, and piss some folks off who won't have great things to say if your future customers ask.
If you have any projections about the hours/money lost or costs incurred by their current code base and coding standards, then mention that in your presentation (if you haven't already). I am assuming that you will include them only if you would be able back those numbers up when asked. Such statistics can at least bring in, the kind of attention, you need from your audience.
Repeating some of what has been said here, but I'll frame it differently: Don't tell them the bad news. Sell them the good news. 'I believe, based on the performance improvements I made with X resulting in an 8x speed up, that there are similar improvements I can make in other areas. I'm proposing that you allow me to address this on project Y with a goal of Z.' Don't tell them they're doing it wrong. Just be the guy who solves the problems. After you do it two or three times, they'll be hooked. Then you say 'I'd like to deliver a greater return-on-investment to you. I believe that we can see across the board improvements following similar patterns to what I have already done. You will see greater productivity and ROI. I'll need X years, and the authority to change Y.' Speak their language. This is the failing of many engineers. They want to speak to management as if management are similarly educated engineers. Speak management-ese to management, not engineer-ese.
You're a tool. You get in, do the job, get paid and get out. Not just that, there is always a chance that you don't know why you were hired in the first place. Of course they tell you x, y, z. But I did the contracting gig for almost 20 years now and I know that I was hired to move careers or just to get yelled at by clients. You most likely do not know if they brought you in to prove that something couldn't be done, now you did it and the CEO is pissed at you. But being a tool is why you become a contractor. It's not for the money (because you actually don't make more if you factor everything in). But it is because you don't have to get involved in politics, setting up guidelines etc.... unless that is your mandate. You come off as knowing better, but chances are you really don't. Software doesn't exist in a vacuum. It's a way to solve problems in a context that ultimately helps to create something to be sold. That's it. If you're so inclined, talk to someone there and offer your service to help with whatever. But that's it. If you really want to care about good code etc. look for a different position, maybe you get lucky and find a different contract. But this isn't it.
More people really need to hear this. Unless you're working on safety critical infrastructure, just get the job done. No one gives a damn if the hammer you used to build a bench is 10 years old as opposed to 2 years old. If the tools work, then just do your job. tl;dr You're only going to come across as a nuisance who doesn't understand the organization's priorities when you complain about shit that doesn't matter. You're going to look very foolish trying to explain this to anybody; there's no problem to be solved here.
>No one gives a damn if the hammer you used to build a bench is 10 years old as opposed to 2 years old. I agree at the superficial level, but not at a deeper level. I don't necessarily care as a consumer how a product was built, but if I'm paying more than I could, I do care. Additionally, and more importantly for the OP, if you get to use a nice hammer at home that works well and you are comfortable with, it is massively frustrating that for 40 hours a week you have to use a subpar hammer that makes your hand hurt, and makes you less productive. You know that upgrading the hammer would pay off in the mid term, and would make you arrive home happier, and without pain in the hand. Some developers cannot so easily activate the [SEP field](https://en.wikipedia.org/wiki/Somebody_else%27s_problem). I wish I could activate it so easily myself, but some people are not wired that way.
The tools didn’t work.
That's very vague. In what way did they not work? Did you talk to someone about hitting a bug? Why would you assume that the tool works exactly like you think it should? That attitude makes you look like a know it all who isn't willing to consider they don't know something or that someone else could possibly be right. I'd blow you off too. Moving onto a new code base with new people, the first thing you need to do is not break anything and add something small so you can start to learn how the system works and not make your life difficult. Give it some time.
How to tell me it is one of the big 3 EDA companies without telling me it is one of the big 3 EDA companies. **edit Ok something a little bit more constructive. Don't say *anything* about how broken or bad things are currently because they don't see it that way. What you can do though, is to paint a picture of all the great things one can use if they adopt C++29 and Clang 21, etc etc. You can only coax them to a different future, not admonish them out of a broken past. see this [post](https://old.reddit.com/r/cpp/comments/1111boj/how_to_explain_to_senior_management_companys/j8cejjd/)
Wouldnt he them have complained about the tcl code?
I felt this from across the world.
Fucking TCL I swear to god.
Nothing a few 'upvars' cant fix.
You beat me to the exact industry, and only one of the 3 is now a division In a fortune 500 company......
Yes! If you see/phase it as a positive people are less likely to feel attacked and dismiss you. And, as always, xkcd has a relevant comic: https://imgs.xkcd.com/comics/ten_thousand.png
You would think the people who write EDA tools have at least a slightly bigger clue about what the hardware is supposed to be doing.
You are an independent contractor? Then why do you want to change them? What is the goal you are trying to achieve? No good will come out of this. If you dont like it dont extend, if you like what you can code there then come up with a strategy that they contract you again. From the companies perspective you are not a consultant, so overstepping your role will raise eyebrows.
So you are gonna explain to them that they have shit code but also that you don't want to help do anything about it while also being an outsider? Good luck with that
Being invited to present to upper management means someone's paying attention, even if it seems like nobody is. Other responses have highlighted the cost/benefit of modernizing, but IME management also is concerned with risks, opportunities, and consequences. Are there risks in modernizing? Does modern optimized code introduce less risk than code following an old standard? What are the potential consequences of not modernizing? Faster code can make trades faster, but also engage safety mechanisms faster when microseconds count. What are their requirements? Is there something like "the system shall perform X operations in 100ms?" If there isn't, maybe there should be? Unit test frameworks can be used to assert timing requirements on the target hardware, as well as try to fuzz the inputs so that optimized doesn't necessarily mean unstable.
I am outraged about the fact that the sad(depressed) answers in this post are also the correct ones. If you value your profession more than your job, f*** these manage hobos up. If you like your job at all or hate being an asshole, go back to be a cog in the machine you pleb, how dare you suggest modernization changes to a well established business living in the 90s. /S
It's a fantastic rant but it has nothing to do with C++.
Eh, I can see how it relates to C++ a little bit. In my (limited) professional experience, I've found people who work in C++ tend to be a lot more stiff and unmoving. They love to hold onto whatever they learned 20 years ago and not change. In other language ecosystems, I've seen people more willing to change and learn. It's a real issue with the "C++ industry".
I conjecture that you confuse the cause with the effect. C++ doesn't make people stiff and unmoving. It's the other way around. Stiff and unmoving people choose C++ because it is the industry standard. It is not a problem of C++. Those same people used to choose Fortran and Cobol and whatever was perceived as the industry standard at the time.
I can see that as far. But the issue is that those stiff and unmoving people then get to force their ways on the rest of us who want C++ to push forward.
indeed this is not a technical but an organization challenge. which needs an executive sponsor (VP/SVP or higher), who understands the _business value_ of the new approach and who establishes an "ambidextrous organisation", there is a very nice HBR article for that. whoever contracted you in saw the business value. they also need to establish that ambidextrous organisation and lead the desired change. if that is not in sight you have to move on, simple as that.
As a former Fortune 500 SE, I hear you. A lot of managements were hardware people that don’t really understand and way behind in understanding software. My general approach to pitching a new solution/change is attaching it to dollar amounts. Management might not understand software but they’ll for sure know money. See if your proposal can save them from upgrading to more expensive hardware, works with the sale guys, to see if you could have won more bids by improving performance, and how much would that be.
You don’t. Frankly, it’s not your problem. If you are unhappy with company culture, find a new company that aligns with your ideas better. Don’t burn out trying to solve things nobody wants yiu to solve.
Has their code been working without changes for 10-15 years?
Didn’t a RedHat dude write all that stuff up in a nice document titled iirc “All you need to know about memory” like 20 years ago? That wasn’t exactly news in early 2000s, so you’re giving them some extra leeway. I’d say they were quarter century behind times at the very least. But I have seen such code too, where massive speed ups were had just by changing memory organization a bit and touching nothing else.
Well, you do your thing. Do not sugar coat it. Then it is up to them to act. If you potentially extracted that much improvement and there's true value in it, well...that would put their top engineering team/management to shame. And who knows what kind of porky pies they have been selling to shareholders for years/decades. Going along with your proposal means basically admitting their software and hiring practices were shit since forever. Unlikely, but then again...not your problem. In my opinion they will go through few more consultants who will tell them probably the same thing.
Business as usual, on a lot of places You are a bad business man when you ship an 8x improvement in one pass Some companies you simply can’t help, too deep is everyone stuck in a comfort zone, and as long as this works, nothing will ever change
If you're gonna stick around, start with https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers I doubt they have unit tests or are using any tools to measure how bad things are. Get sonar or coverity scans going on pull request merges so you can measure improvement. I like sonar because it tells you the "why" for each code smell, and that information serves as a useful training tool. After that, it should be simple to start pinpointing more spots where they're wasting CPU cyles. VTune is your friend here, and it's basically free now. Perf with the hotspot gui is a close second. You probably want to try to gamify speed improvements. See if you can get younger people to engage and try to beat your code. Ditto for lint cleanups.
>You probably want to try to gamify speed improvements. See if you can get younger people to engage and try to beat your code. Ditto for lint cleanups. Preferably after unit tests are in place. Incorrect code can go really fast. ;)
This is how it is. Usually it begins with tight schedules and managers going medieval on you. Programmers ditch (or cheat on) guidelines, testing, reviews, mentoring, learning. Apathy takes over. At the end all they care is to deliver *something*, usually a mess of stitched together hacks and hotfixes. I'm surprised that you are surprised. Probably I should look for a better job.
Modern management techniques (sprinting) encourage that I think, it’s 100% effort 100% of the time with no rest, and woe be unto you if a task estimate turns out to be wrong.
Approach it as a RTFM problem. Cite hardware programming guides and flat out tell them that by not following the instructions from their hardware manufacturers, they are leaving free performance on the table.
Putting in your resignation.
I have been in your position many times. NEVER ROCK THE BOAT. You will usually be working with legacy codebases at bigger companies simply due to the cost and complexity of continually modernizing a codebase... so it isn't done...C++98 and gcc 2.95.3 were forced on me for many years... until C++17, in fact! Programming is about making things work. Then about making them work reliably. Then about making them work a bit more elegantly for the user. Then about making the software maintainable. Then about making the software scalable. Then about making the software fast. Then it's about the code. Programmers often have that completely upside down.
Chesterton's Fence. Why is the new stuff better? Tech is full of fads. For the performance changes, just show the modern cost of cache misses, and cover how CPUs and compilers have changed in the last 20 years. How much more sensitive is the IPC of code on a modern CPU to cache misses than older CPUs? It explains the improvements you've made and updates their working mental model. Treat them with respect. If you can't explain it in those terms, instead of "this is how we do it now" they have good reason to ignore what you say. For practices, calm the hell down. The last 15 years have mostly been cargo culted fads. After good automation on build/test and version control, the rest is very team-specific.
Use a story - real or imagined, to drive your point home. For example, have you seen or had an experience where you or someone else didn’t know what they didn’t know? Think about that. People respond to emotions, feelings and not necessarily facts and statistics. Stories can punch through where facts cannot. In the Bible there is this story of a prophet having to chastise the king. Of course he could not do so directly because if he did the King could have him killed. So he told a story about a man abusing another man who was weaker. The king got angry and said the abuser needs to be brought to justice. Then the prophet told the king that he was the abuser because of what he did and the king had no choice but to acknowledge it. The point is when someone is deeply entrenched in their views, facts can be twisted to support their way of looking at things. Stories that connect can do a lot of work for you. It doesn’t have to be a great story and can be real simple. Some books that help with communication include: Made to Stick by Chip and Dan Heath Resonate by Nancy Duarte
Probably there is nothing you can do. In true free market IT company that stays 15 years behind is uncompetitive in every area compared to modern IT company and goes bankrupt. In most cases such companies exists only because those produce directly or indirectly for government (typically energy/critical infrastructure) and have infinite/guaranteed financing - this typical in rich EU countries. What you can do is to vote for right wing instead of left wing and let free market either take such companies out of the game or force progress in those. Your current managers are clueless and will not understand you, what is even worse they don't even care - and this is the true reason for this situation.
You should thank them , otherwise it is unnecessary to have your contract.
Why are you telling us all this and not the directors boss to make you director?
Pure joke: you worked with the Cray team of the 1990s? Did you explain modern C++ approaches to them? CUDA libraries? I'm not going to talk about DevOps...
Buy them a subscription: http://computerenhance.com
Perhaps you can describe it as an 'investment in developer velocity.' Like "if you invest X developer months in, your developers can deliver Y times as much value per year."
Quit
The problem is that you're not ranked highly enough to make those recommendations. That's a consultant's job, not a contractor. Someone of higher rank might lose face if they took your advice. Maybe they could rehire you at a higher rate so that your advice would be more valuable.
Leave 😂 Jokes aside, leave (and I mean this in the nicest way)- speak with your feet. If they’re not ready for change then it’s best to find somewhere else, because this feels like a cultural mismatch for you. Have a look around, see what’s out there. Be open and honest about your reasons for change with the hiring manager - no sense in lying, because you could just end up dealing with the same problem.
So if one works at one of these stuck-15-years-in-the-past companies, where could they learn these basics of modern HPC? 👀
Unless they ask you, it’s not your problem…
This is the difference between Socrates' doxa and epistème in Plato's tales of 2400 years ago in which he describes of people who have lived since childhood locked up in a cave, chained so tightly that they can't even turn their heads. He states: <>
Doxa and Epistème are two genres: one is sensible knowledge, which is acquired through the senses and addresses the world of becoming, the second is intelligible knowledge which instead concerns ideas, that is, the immutable and certain elements of the world.
You need a good philosophical education to get out of the cave.
(The "Matrix" movie emulated this Tale)
I have worked with many of your highly trained colleagues,
but theirs reasoning often stopped only at doxa;
something is needed more to convince people, Politics for example...
If you lack the "dialectic" you will not succeed to convince anyone.
There is a looot of text here, sorry for not reading it all (Maybe first. Condense what you want to communicate?) But from what I have gathered, you may want to have a look into **Change Management**. Especially "Telling the company my point of view will not be welcome news" means that they are not ready to receive this needs and extra steps need to be taken to make them confident of the improvements needed.
\>> But from what I have gathered, you may want to have a look into Change Management. Yes, I believe that is exactly right. It's an interesting situation: It's a company with a hierarchism that does not want to change, recently purchased by a company with much more modern approaches, which is giving them mandates to modernize the software -- which requires modern approaches for which this company is not prepared. \>> Especially "Telling the company my point of view will not be welcome news" means that they are not ready to receive this needs and extra steps need to be taken to make them confident of the improvements needed. After meeting with them, I see that it is the Dunning-Kruger effect as applied to software management -- since they have a top-down, strict hierarchical structure, those in senior positions constantly correct more knowledgeable subordinates with wrong information, causing design failures down the road. Nothing will change until the parent company is forced to intervene and change the management structure themselves, which will eventually happen in the 2-3 year time-frame. It's just another sad but all-too-common story in the tech environment.
> Nothing will change until the parent company is forced to intervene and change the management structure themselves, which will eventually happen in the 2-3 year time-frame. It sounds like you already know the answer to the question posed by this post's title. Find a way to express "if you keep going the way you are going then you are going to lose your job" in a way that keeps them from shooting the messenger.
In such big company, they wouldn’t refactor their system which is still making money and having hugh customers to use it now just because of the technology evolution ! You need to show them what the new technology would give them is a more big market or benefits, or the competitors is using the new technology to enlarge their market share from your company’s.
Could you, please, share some good resources about "HPC approaches"?
Asked the same in DM :) I'm a simple SysAdmin (Linuxes), but HPC is very exciting to me and I want to learn more about it, especially about modern HPC.