how to become a true scum master:

- formulate jira tasks for your inferiors as vague as possible, best they don't make any sense

- before sprint start, ask the subhuman being to estimate storypoints, and if they say they can't really tell with this description and choose the highest estimate, say "okay, let's estimate it to one sprint length", so they can actually work on it within one sprint (which makes total sense)

- if the scum dares to question the content of the ticket and begs for more details, be like teflon and give no useful answer at all. if they continue asking for a meeting to discuss the ticket, tell them to have a meeting with a coworker about it (who also has no clue). don't be available for them because you have more important stuff to do.

- bully them during daily standups that they didn't create clear subtasks from this task and criticize them because you have no idea what they are doing. tell them they are having performance issues and suspect them to sit on their lazy asses all day.

- criticize the team in general for bad performance, bad item tracking and never say something nice, to make sure everybody loses even the last bit of intrinsic motivation for the project.

stay tuned to learn how to make yourself a skull throne out of those filthy dev smartasses ^.^

the ultimate dick move: invite your dev to a meeting, scheduled a few weeks ahead, with title "performance issues", without any further comments or notice in advance. when dev, seeing this invitation and feeling kicked right in the face, asks if this meeting is about a certain project or their individual working performance, just answer "both" without any further comments. if they have any more questions about it, just tell them you have no time to answer because meetings.

!rant

After over 20 years as a Software Engineer, Architect, and Manager, I want to pass along some unsolicited advice to junior developers either because I grew through it, or I've had to deal with developers who behaved poorly:

1) Your ego will hurt you FAR more than your junior coding skills. Nobody expects you to be the best early in your career, so don't act like you are.

2) Working independently is a must. It's okay to ask questions, but ask sparingly. Remember, mid and senior level guys need to focus just as much as you do, so before interrupting them, exhaust your resources (Google, Stack Overflow, books, etc..)

3) Working code != good code. You are an author. Write your code so that it can be read. Accept criticism that may seem trivial such as renaming a variable or method. If someone is suggesting it, it's because they didn't know what it did without further investigation.

4) Ask for peer reviews and LISTEN to the critique. Even after 20+ years, I send my code to more junior developers and often get good corrections sent back. (remember the ego thing from tip #1?) Even if they have no critiques for me, sometimes they will see a technique I used and learn from that. Peer reviews are win-win-win.

5) When in doubt, do NOT BS your way out. Refer to someone who knows, or offer to get back to them. Often times, persons other than engineers will take what you said as gospel. If that later turns out to be wrong, a bunch of people will have to get involved to clean up the expectations.

6) Slow down in order to speed up. Always start a task by thinking about the very high level use cases, then slowly work through your logic to achieve that. Rushing to complete, even for senior engineers, usually means less-than-ideal code that somebody will have to maintain.

7) Write documentation, always! Even if your company doesn't take documentation seriously, other engineers will remember how well documented your code is, and they will appreciate you for it/think of you next time that sweet job opens up.

8) Good code is important, but good impressions are better. I have code that is the most embarrassing crap ever still in production to this day. People don't think of me as "that shitty developer who wrote that ugly ass code that one time a decade ago," They think of me as "that developer who was fun to work with and busted his ass." Because of that, I've never been unemployed for more than a day. It's critical to have a good network and good references.

9) Don't shy away from the unknown. It's easy to hope somebody else picks up that task that you don't understand, but you wont learn it if they do. The daunting, unknown tasks are the most rewarding to complete (and trust me, other devs will notice.)

10) Learning is up to you. I can't tell you the number of engineers I passed on hiring because their answer to what they know about PHP7 was: "Nothing. I haven't learned it yet because my current company is still using PHP5." This is YOUR craft. It's not up to your employer to keep you relevant in the job market, it's up to YOU. You don't always need to be a pro at the latest and greatest, but at least read the changelog. Stay abreast of current technology, security threats, etc...

These are just a few quick tips from my experience. Others may chime in with theirs, and some may dispute mine. I wish you all fruitful careers!

okay, this is fucking ridiculous. my bank released an update of their pushTAN app and I just had to call their service center to learn how to interact with the "new" UI to release an order.

quiz: how do i release an order in the UI shown in the screenshot?
(auftrag freigeben = release order, ablehnen = decline)

Pretty sure this is a new recruiting ploy but how can I confirm?

Dear LinkedIn,

Try training your AI model without using captured data of real recruiters and their dodgy practices.

excel as a database? anyone?

Somebody in my neighborhood is helping me get a job. I'm 15. He's awesome.

ComputerToucher: *opens Jira ticket* Dev team needs tokens for the APM for a new app with multiple tenants. Ezpz. Hey, developer. Do you want one golden token for all of your app tenants or would you like us to generate one token for each?

Developer: Let’s have a meeting to discuss it.

CT: It’s…an exceedingly simple question. One token or 4? Which does your app support?

Dev: Yeah I think we should discuss with this with the platform team, can you set up the call?

CT: (Internally) I am the platform team? Do you not know how your applica-never mind I’ll just ask the PM directly.

CT (in chat): I’ll ask PM to schedule the call.

*Goes back to Jira ticket, changes priority to 4, removes ticket from sprint entirely, picks something else to work on*

We've had a bunch of flaky tests in our repo for a while now that no one could be bothered to fix; we'd just re-run ci until it's green. Today I looked into it and I was inspired to make this meme, because I lived through it.

Adding logs to investigate just lowered the fail rate making investigation more difficult. I do have an idea of what it might be though so, we'll see tomorrow.