I am a real programmer damnit!
-
@CodeJunkie said in I am a real programmer damnit!:
DevOps can go fuck itself
It’s generally unwise to speak ill of your sponsors, if you know what I mean…
-
@Zenith said in I am a real programmer damnit!:
You'd find those distracting emergencies would be fewer and further between if the responsibility and accountability fell on the same team if not person.
That's the idea behind all those infrastructure as code tools: The developers should know best what environment the program needs, so they maintain a description of said environment. All operations has to do is maintain the bare-metal servers and the systems that consume said description (e.g. Kubernetes).
It's incredibly frustrating when you join a new team and nobody can tell you what a working build environment looks like, let alone how the application will be packaged in the end. Not to mention unprofessional. If you delegate the responsibility to define those environments to an entirely different department, it'll only cause problems and frustration.
-
real engineering is an elitist myth. i build lego structures therefore i am a real engineer. my child builds sandcastles, therefore my child is a real engineer.
standards are oppressive racist colonialist social construct.
-
@sh_code said in I am a real programmer damnit!:
real engineering is an elitist myth. i build lego structures therefore i am a real engineer. my child builds sandcastles, therefore my child is a real engineer.
standards are oppressive racist colonialist social construct.
I'm a trolleybus mechanic
therefore I am a real engineer.
-
@dfdub said in I am a real programmer damnit!:
@DogsB said in I am a real programmer damnit!:
YMMV but from what I've seen is that backend developers are expected to pick it up and manage it.
No, the infrastructure team is supposed to manage it and all the developers are supposed to do is provide the pod definitions. Which is kind of the whole point of DevOps: The developers declaratively define the infrastructure they need and then start their containers on actual infrastructure managed by operations, thus bridging the gap between dev and ops. Sure, you can have a dedicated "DevOps guy" on your team who handles that, but that's entirely optional and potentially not even a good practice.
My experience has been
infrastructure team? Fuck that. Too expensive. Let's have the developers do it. We'll make them devops.
-
@dfdub said in I am a real programmer damnit!:
That's the idea behind all those infrastructure as code tools: The developers should know best what environment the program needs, so they maintain a description of said environment. All operations has to do is maintain the bare-metal servers and the systems that consume said description (e.g. Kubernetes).
Ideally, developers would write code with a mind towards making operations simpler, and operations would run things while providing the feedback to development that is required to fix issues. When that happens, when the two sides actually talk to each other, good stuff gets done rapidly; you end up with code that deploys easily and which provides relevant and timely feedback on its status (along with doing its other duties).
It's not a never-ever thing, but it's definitely not as common as it would be nice to have.
-
@dkf
I'm not going to lie: I curse at Kubernetes and Docker very frequently. But those tools really facilitate exactly those interactions between development and operations, because collaborating on Docker images and Pod definitions is so much easier than having hour-long meetings to explain requirements and deployment problems. Proposing a change to a Dockerfile is much easier than talking about an abstract problem.
-
@dfdub said in I am a real programmer damnit!:
so much easier than having hour-long meetings
Say no more.
-
Anyone using term like real programmer is, in my eyes, just full of himself (maybe even full of
).We can distinguish professional and amateur programmers, in both senses. We can distinguish good and bad. Most of you here in this topic actually write about people who are "good, competent and experienced professionals" - but there are lots and lots of "real" programmers that definitely don't meet these criteria.
is the utter lack of humility on the site dedicated to shit prevalent in our industry. Do you even read the main page anymore? Maybe you should browse through the archives...
-
@Kamil-Podlesak didn't RTFA, eh?
But it sure does work. I've noticed that when software lets nonprogrammers do programmer things, it makes the programmers nervous. Suddenly they stop smiling indulgently and start talking about what “real programming” is. This has been the history of the World Wide Web, for example. Go ahead and tweet “HTML is real programming,” and watch programmers show up in your mentions to go, “As if.” Except when you write a web page in HTML, you are creating a data model that will be interpreted by the browser. This is what programming is.
-
@Kamil-Podlesak said in I am a real programmer damnit!:
Do you even read the main page anymore?
The what?
-
In our company "programmer" is the entry-level job, and as your career progresses you should move on to e.g. "software architect". So, then, if someone who does some basic programming wants to be called a real "programmer", be my guest!
-
@CodeJunkie said in I am a real programmer damnit!:
@dfdub said in I am a real programmer damnit!:
Well, yeah, but having to debug infrastructure issues in production as a developer is not "DevOps"
This is generally what it is....not that I'm saying it is good or correct, but usually the case. Where I'm at right now we have no operations department.
@dfdub said in I am a real programmer damnit!:
@Zenith said in I am a real programmer damnit!:
I literally have no idea what DevOps is supposed to be.
It's supposed to be an umbrella term for practices that bridge the gap between development and operations. The most common ones would be CI/CD (developers test their code in a realistic environment) plus release automation and all those "infrastructure as code" approaches (Dockerfiles / Kubernetes / Ansible / …). So basically all the tooling that helps automate releases and deployments so that both developers and operations can focus on the important stuff.
This isn't quite the same as how I got introduced to DevOps in 2010+something.
The point back then was that Development and Operations weren't really talking to each other. Instead, Development would send a release with a vague installation manual, then Ops would reply with "your shit doesn't work, please fix and clarify" thus sowing enmity between the two departments.
So what DevOps was all about is to have "Developing Operators" - i.e. people with a clear understanding of operations helping development build a shippable product by helping to write installation manuals, init scripts, deployment scripts, ... as part of the usual development lifecycle. The release then includes all the deployment materials, rather than it being tacked on at the end (and thus done by separate departments, with no "lessons learned" shared between those departments).
Even before Docker was a thing, automation tools were being researched to do server maintenance, and by extension do deployment and configuration (see e.g. Ansible, Salt, Chef and Microsoft's implementation of Desired State Configuration). It is from this time that the saying "prefer cattle over pets" was introduced to mean that people should stop thinking as "this our blessed server, nobody break it" and instead should think of "here's how we can quickly setup new installations from scratch". In that case, operations becomes slightly redundant as there's less manual actions happening.
I only wonder if @CodeJunkie's company started out with an Ops team and fired them as DevOps was so successful, or if it started out as a Developmestuction environment which started becoming more professional by separating things a bit (but not enough to leave developers to working on releases and hiring an ops team for the day-to-day maintenance).
-
@dcon said in I am a real programmer damnit!:
Just a bad translation from "The programmer who descended from a high"
Jesce mistr od nebe nepadl (a master has not fallen from sky yet).
-
@dkf said in I am a real programmer damnit!:
“Real” programming, which takes those happy paths and adds in all the stuff for dealing with awkward edge cases and ensuring that things are secure and scalable and maintainable and so on. ...
The third is where professionals are usually operatingHa! The third is were you should have some professionals working, but ... c'mon, what's your experience with your cow-orkers?
-
@BernieTheBernie said in I am a real programmer damnit!:
what's your experience with your cow-orkers?
The first drafts of their code are almost always shit (except usually for the exact thing that they're built to do), but then they make them better so the fact that things start bad isn't a big deal; I'd worry more if they were engineering their proofs of concept to be perfect before letting anyone else look. One of the things I've invested a lot of effort in is getting all our systems to use automated testing as much as possible, on the grounds that we'd like to find as many problems as possible before our users do.
We do extensive CI, including not just testing but also multiple code style and quality assessments (important for Python code). CD doesn't make so much sense for us (apart from our documentation) as the supporting server components almost never change. In fact, there's one component that can only be changed with the aid of a flash drive and a lot of patience, but it's not user-exposed so we paper over the bugs with the mediator service. The
is strong with this.
-
@Gąska said in I am a real programmer damnit!:
@Kamil-Podlesak didn't RTFA, eh?
But it sure does work. I've noticed that when software lets nonprogrammers do programmer things, it makes the programmers nervous. Suddenly they stop smiling indulgently and start talking about what “real programming” is. This has been the history of the World Wide Web, for example. Go ahead and tweet “HTML is real programming,” and watch programmers show up in your mentions to go, “As if.” Except when you write a web page in HTML, you are creating a data model that will be interpreted by the browser. This is what programming is.
Oh, the article is one big
, absolutely. Mainly because it completely misses the point and it instead of clarifying the confusing mess of various terms, it makes them even more muddied.
the term "programming" is also used (for quite long time, probably more that more people here can remember) for "advanced" configuration of non-turing devices like CNC or PLA (it's even in the name!). On the other hand, there is no real reason why "software development" should actually be limited to code.Discussion about "real programming" is kinda interesting... but far too often it devolves into "real programmer" which is definitely something different.
-
@dkf said in I am a real programmer damnit!:
We do extensive CI, including not just testing but also multiple code style and quality assessments
You lucky bastard! My cow-orkers even destroy unit tests and care the fuck about it...
-
@BernieTheBernie When I joined the team, the guys that were already here were mostly just spending their time running round fighting fires trying to make everything not collapse every time someone breathed in the general vicinity. Given the level of rolling catastrophe, they were doing a good job, but they knew that to change for their own sanity. The first thing I really did was setting up CI and fixing tests so they ran, tested something useful, and didn't randomly hang and break the whole build. I've been gradually smuggling in stricter checking ever since, but I'll usually try to fix things up as much as I can before making anything stricter. The combination of our unit tests and our integration tests now get a very large fraction of our code covered. (Not 100%, but that requires crazy techniques that boost the vomit factor too high.) The tools don't get everything right, but they catch many problems.
It's been a good project to work on after the shitshow of the previous one. (That was doing cool stuff with nice people, but it's internal management was fucked up and very stress-inducing.)
-
@Kamil-Podlesak said in I am a real programmer damnit!:
the term "programming" is also used (for quite long time, probably more that more people here can remember) for "advanced" configuration of non-turing devices like CNCwashing machine orPLApressure cooker
-
@Gąska said in I am a real programmer damnit!:
@Kamil-Podlesak said in I am a real programmer damnit!:
the term "programming" is also used (for quite long time, probably more that more people here can remember) for "advanced" configuration of non-turing devices like CNCwashing machine orPLApressure cooker I can't just program large server systems, I can even program the VCR!
-
@PleegWat da real OP!
-
-
@loopback0 I don't think I've actually had to deal with a VCR which didn't have an OSD. Which does make it significantly simpler.
-
@PleegWat Before that, programming them was like programming an old car radio. All of the buttons had different behaviors depending on what other LCD icons were lit up. Not modern screens like on a PSP or even a GameBoy but the old Tiger Electronics handhelds or cheap digital wristwatches. A truly primitive horror...
-
@Zenith said in I am a real programmer damnit!:
All of the buttons had different behaviors depending on what other LCD icons were lit up.
VFD, not LCD.
-
@Zenith said in I am a real programmer damnit!:
depending on what other LCD icons were lit up
And they do different things when they're flashing. Of course.
-
@Zenith said in I am a real programmer damnit!:
@PleegWat Before that, programming them was like programming an old car radio. All of the buttons had different behaviors depending on what other LCD icons were lit up. Not modern screens like on a PSP or even a GameBoy but the old Tiger Electronics handhelds or cheap digital wristwatches. A truly primitive horror...
The good old times!
-
