Ditto, PP also here, sad ...

About 6 years into doing DevOps and getting better every year. Upper management: "yeah...it's not making any revenue, so better stop doing it". Literally the only reason we get products and services done is DevOps. How clueless can you be...

0

Arch since 2010. Still using the same installation as I can update it little by little when the need arises.

Point of the meetings is to create shared context and consensus. Do you see it happening ? Or do you just do the "ceremonies" and nobody is mentally invested in actually achieving anything.

@krz1 No great highlights or bad stuff to give sorry. Basically stuff just works. We refactor our libraries quite a lot, so that helps the development. Failure detection, fallbacks and input data integrity checks have been solid performers and common now to most processes due to refactorings. Techwise things are very simple and almost all problems that seem to need ML, OCR etc. are easily worked around with a process change. Most headaches come when a new tool needs to be introduced and its automation maturity is low compared to the tools we already support. As s developer you just have to be very systematic, prefer boring and simple code and always come back and refactor stuff from processes into libraries.

There is a DB designed for this use case. Quite handy IMHO.
https://github.com/attic-labs/noms

Git

@devTea yeah, I know. This manager was tasked with competence roadmapping C++ knowledge. I would presume some basic knowledge selfstudy before layoutting some strategic competence map where languages, standards and platforms happily mingle with no correlation to the real world. In worst case we the developers need to make that "it's just a plugin" a reality if somebody signs a contract ... I value my sanity and happily mentor managers via discussions rather than writing any code about the nonsense they utter. Their heart is in the right place, but head has been stolen from a previous topshot manager.

Nice having you back.

Everything you can automate from security tooling and practices is my advice and train the people. Devs for security minded coding, Ops for security minded usage and adversial testing. On top of that chaos engineering practices.

@MacDev with your effort you can set the standard for others. You can leave a lasting legacy. Continuation of your work with quality set by you is easier than doing something else.
Bad quality leads to more bad quality most of the time. Good quality leads to more good quality. Working against the trend is more effort, so we continue in the vein of our predecessors.

If the product lifecycle is very short then bad code, because I am not burdening myself or others with stuff that will become obsolete quickly.

Otherwise good quality, because of maintainance burden to me and others and the need for constant evolvability.

Github/Gitlab. SO is nice, but I could do without it just fine.

@platypus Python and Robot Framework

Processes based on hour tracking system (overspending, underspending, wrong or missing data, resource utilization etc), Internal invoicing (fix data autom. if enough correlative data available and write corrected invoices automatically back to system, tax deduction stuff etc. ), Instruments and laboratory equipment scheduling and allocation (bad utilization is super expensive), onboarding process automation (quizzes, tests and links to material from info sources to chat/email with encouragement and contact info/meetings to mentors)

Those are just few

We use RPA quite extensively currently. We tried UIPath and Workfusion, but the tools themselves became a bottleneck in the long run. Now we have our own lower level RPA tool which everybody likes more. We ditched the drag and drop UI approach and do everything via coding and inhouse RPA libraries.
Use cases are from every part of our organization from Finance and HR to actual product development teams and individual coders.

...comment from the better half..."they are not even remotely same looking". So I might be alone on this afterall :P

Is it just me, but I can't get over the fact that the guy on the left looks like Stanley Tucci the actor. Every time I come back to this story my initial thought is "cool, I didn't know Stanley Tucci was a developer before Hollywood ..."

I would choose RPA just on the merit of usually getting to see the end user's happy face. From tech side both can be fullfilling to do. I have done AOSP from kernel to apps and RPA coding also. They were different, but with RPA I felt I made an impact.

@M1sf3t just felt wrong while watching the video. Passion about stuff is not so clear cut. Answer made total sense, but didn't feel appropriate.

...fun!

7

In my company almost all of the best developers are dedicated to architecture, subsystem design, TDD, CI and CD. We have a culture of enforcing best practices via technical solutions. When you are a beginner nothing helps more than good tooling and enforced rules. When you are advanced enough you know when and how to break/bend the rules.

Of course the downside is frontup investment and complexity that has to be approved by the higher ups.

As a Tech Lead it is my responsibility to provide proof and prediction to justify the investement and to oversee the plan that we don't take shortcuts. Justifying part is always a real PITA, but after that seeing all the best practises pay off is priceless.

With the assumption that you have up to date local branches dev and master

@dev git reset --hard <bad commit>^
@dev git rebase master
@dev git checkout master
@master git rebase dev

1. Remove bad commit from dev
2. Rebase correct history from master
3. Switch to master
4. Fast forward rebase master to same history as dev (this should be no-op, but to be sure)

Nanomsg nextgen is what you are looking for. Socket based and handles all common messaging patterns. Just read the feature list on the GH page.
https://github.com/nanomsg/nng

If your first priority are your customers, then your employees always come second. Like a coach looking out for the fans instead of the team. I can see lot of disengagement and churn in that team.

Hope you make it 😎

Solid 8, but nearing 9. After I can handle the "plumbing" if needed then 10.

@cursee Older