Docker, Docker, Docker... It is not the perfect pill let me tell you.

Scenario: Developer packages everything he needs into his container, the stack of who knows what on what versions, but hey, it works right? Then developer hands over container to IT Operations (via kubernetes), and expect Ops to be like "I'm totally ok with not knowing what's in there, or what standards it adheres to.... Suuurrree"

What developers want is a consistent development through deployment process, they want to focus on code, and NOT on perceived headaches inflicted upon their Ops people. So sure Docker seems like a key that fits that hole, but when you look at ongoing support, CI/CD pipeline, and scale, it becomes a nightmare.

Please, for the love of God, look into CloudFoundry. I'll leave it at that.

Give up and be a copy and paste coder like the rest of us

@runfrodorun trust me, I would do rather run Ubuntu Gnome, or Fedora over MacOs.

Dude, common. Lazy.

Seems light on the programmers.

Any self respecting programmer would see that ratio and stay away.

Maybe the source control repository and the CI/CD pipeline should be RBAC secured so that "mistakes" cannot happen. Maybe, just maybe, the person in charge of TFS should ensure that it is compliant with the architected processes.

@watt I was about to reply the same.

I've done that. Learn from the trial and error mistakes the recode it cleaner.

work of art. hat is off to the engineer.

just like anything else, classic asp can be written well, or like crap.

each of the guys you listed did amazing things without waiting for someone to give them a job.

Don't hate on table structure

I'm gonna vouch for the Sr dev here and say that it was a note to his manager why his task took longer. it was not the Sr dev job to educate you, but it is the job of the manager. now if the manager didn't inform you, it use it as a coaching opportunity, then it is the managers fault, not the Sr dev. That said though, to the point of the raise, if it is to say that you were not exceeding expectations, based on peer feedback, that may be fair. Usually it is only the top performers who get the top raises. (coming from a former Dev, Sr Dev, and Manager)

@tisaconundrum sorry, that was my rant on his rant... I found it comical.

I'm sorry, but "DevOps" doesn't fix this problem, unless of course you have created some kind of automation script to reboot the machine, but even still DevOps as a methodology neither fixes your access problem to reboot the server, nor does it address the fact that some faulty code in the application caused it in the first place. however, if you consider agile part of DevOps (but is not in of itself) it may help you fail faster and fix the problem sooner... or better yet, create a user story to be included in the next sprint that say you want to be able to call an API to reboot that server from a cell phone... then maybe the. you can say that DevOps, as a "thing" helped you with this problem.

Great resume item.

@shekyb true. like the appeal of the main challenge is overcome, and a lot of the menial tasks can be done by a lower level programmer.

@wgroenewold that's funny.

have to try this one. I chuckled with a "I could see that"

are you saying that we don't have to be politically correct on here?

communication. expectation. level set assumption.

there's allot to be said regarding security, memory management, and scale as well

just like any tool, you have to know how to use it.

such is the case when you only program in Python or Node and simply trust it's so called ability to know the type cast.

each of the characters are very stereotypical. we all know "that guy"... just like when he did Office Space, so we'll done.

that's why I had to buy a second laptop to get work done. I figure it's a tool of a job.

damn auto spell correction

meant to say "code something"

@danner26 true.

and...?

and multistream upload