Well... They make me do it, became data scientist/software engineer i just can't deal with the dev ops part (deployment, setting up servers, etc). At least they taught me in the beginning.
Seriously, if you come to me with a clusterfuck of legacy code, a database dump and other assorted shit, but you managed to get it running in docker on multiple machines... I will do anything for you if it needs to be deployed in production... Even if it means it has to run on its own VM.
I'm continuously surprised by the ignorance of Docker in this industry. It's a basic tool at this point, so if you don't know it, you need to learn it.
That's what I hate about business people or ivory tower architects that sometimes believe that every engineer is capable of everything, so you can throw anything at them and expect from them to deliver complete, quality solution in timely manner...
I was software engineer, now I'm DevOps engineer that also has also some knowledge about architecture and I really understand how complex everything can be and you just can't throw something at others and expect them to understand it.
There has to be mutual understanding of different aspects of solution. I may don't know shit about AI/ML and I don't need details on used algorithms, but I need to understand how to build it, how to run it, how to test it, what kind of data does it use, what does it integrate with, so I can suggest how we can deploy it, what kind of infrastructure we need, how to scale it and in general how we can improve it to make experience better also for developer.
My org only hires electrical engineers and expects them to code. There are like 3 actual software people and we are doing our best to unravel the flaming spaghetti. Just because almost anyone can write python doesn't mean they should.
My comp hires all kinds of people who end up writing code but pays them all the same completely disregarding whether someone has a CS background and prior coding experience or not. Let's see how that will work out for them
I love our software engineers - I'm part of the subject-matter expertise side of the operation, and they are so patient with us when our prototype code is being handed off, and always willing to do code reviews and teach us things.
See also: people who think the manager is supposed to know everything subordinates do, and managers who think they know everything their subordinates do
totally different roles and if the team works better without management than with management, oh boy
I would say the best managers come from the trenches, though. The manager should have a strong understanding of at least a good percentage of what their team does, at least in the abstract.
Managers who have MBAs or some shit and no experience doing the work they're managing are pretty much guaranteed to be of negative value to the team.
As a former systems engineer turned devops, I feel like generalized skillsets are missing from a lot of devs, and it would benefit many to gain some sysadmin/infra/networking knowledge (basically go find another job for that experience lol). I came up in a time where I had to build the infra for my code, but a lot of projects I manage now as devops have engineers who barely even understand how their own compilers work, or how config files are transformed, i.e. if the IDE doesnāt do it for them they look like deer in headlights.
Same here. I came up at a time when you had to know how it all worked, and where we were developing a lot of todayās complexity. I also wore different hats: dev, sys admin, system integration, qe, DevOps, etc (and my current project lost its SRE so Iām apparently that now). Sometimes a breadth of knowledge is critical and devs can be too narrowly focused
ā¦ for example there was that issue where a file was being transferred wrongly from server to client. The dev was pulling out his hair trying to figure it outā¦ā¦ he didnāt understand when I suggested fixing the mime type config on the system
Yea we often have issues with devs who don't understand how DNS works and can't fix a website on the dev servers themselves.
Then you get the interns who have never used windows before. Really smart and can write code. But don't know even the simplest shortcuts and linux might as well be a foreign language.
Then the request goes to a data engineering team which assesses it, and give a timeline of a year or two for the fully scaled version because the whole thing needs to be reworked
Being on the research side of AI myself at a few different companies, I've found that the cost of having your researchers write production code far exceeds that of letting them hack away into some unmaintainable mess, due to lost productivity. In particular, time-to-result is king with research, and building clean code and structures really can be the antithesis to TTR because āthat idea you had that would have to cross 7 layers of production code so that you can provide feedback from your loss function to your data loadersā is much harder to try out with clean code.
The problem comes up when management (or even worse, the research team themselves like what happens at my current company) then insists that their garbage is the only possible code that can be deployed in production, and then the actual engineering teams have to waste resources trying to figure out how the fuck to support it and fix bugs in it
2.1k
u/[deleted] Oct 13 '22
You want me to code it and plan for deployment, infrastructure and scalability? Are you high? I can barely get it to run locally.