LinkedIn is an alternative reality unhooked from the rest of the world, where hypocrisy and arrogance meet, creating Leaders, Experts and Analysts.

- Every company is an industry leader globally.
- Every offer is life-changing.
- Every normal person suddenly is an expert in his field
- Each candidate is an expert in time management, customer relationships, and software development priorities.
- They are all happy to share their achievements in a disinterested way
- They all deal with important issues, with great reflections on the meaning of life and reality around us
- Each written post usually starts with a question followed by a life experience
- Companies are dynamic, they change their internal processes on a daily basis

Please shoot me, I've had enough of this shit.

- Few companies are leaders globally
- The offers you make are traps and I always have to look for where the bullshit is.
- You're not an expert in your field if you've been doing the same thing for 10 years without moving your ass out of that chair.
- If you were a time management expert, I wouldn't have to call you every week for unresolved tasks, and I wouldn't even have to do 150 meetings to postpone the goals set. Exactly what is your experience with the customer? Because by heart shutting up and always saying yes is not a good way to get the job done.
- I have great news for you. Nobody gives a shit about your work successes. At most they're envious.
- If you really are such a deep and introspective person... how the fuck is it that working with you is hell?
- Copying a quote from a website and then building a narrative on it doesn't automatically make you a superstar
- Companies, especially the largest ones, take years to change and if they do it is because there is the economic motivation behind it, not because they are visionaries.

This rant was written by scrolling through my LinkedIn feed.

!!office drama

I haven't been around much in recent weeks. Due to family illness, christmas shopping, dealing with estranged parents, and brooding over the foregoing, I haven't had a lot of time or energy left to myself.

tl;dr: The CTO ("API Guy") is ostensibly getting fired, and I might be taking over his job. I don't know if I should accept, try to stave this off, or simply flee.

------

Anyone who has been following my recent rants knows that API Guy is my boss, and he often writes terrible code. It's solid and unbreakable, but reading it is a *nightmare.* One of our applications is half the length of Leo Tolstoy's War and Peace, and it's difficult to tell what code is live and what amounts to ancient, still-active landmines. This is one application; we have several, most of which I've never even looked at.

Ostensibly the code is so terrible because the company grew extremely quickly, and API Guy needed to cram in lots of unexpected / planned-against features. From what I can see, that seems about right, but I haven't checked timeframes [because that's a lot of work!].

Here's a brief rundown of the situation.
- API Guy co-founded the company with the CEO.
- CEO and API Guy have been friends for a long time.
- CEO belives the company will fail with API Guy as head of tech.
- They could just be testing me; I have zero way of knowing. API Guy seems totally oblivious, and CEO seems sincere, so this feels pretty doubtful.
- CEO likes pushing people around. CEO believes he can push me around. API Guy doesn't budge. (I probably won't, either, except to change task priorities.)
- API Guy's code is huge and awful, but functional.
- API Guy is trying to clean up the mess; CEO doesn't understand (maybe doesn't care).
- Literally nobody else knows how the code works.
- Apart from API Guy and myself, the entire company is extroverted sales people.
- None of these sales people particularly like me.
- Sales people sell and sell and sell without asking development if they can pull enough magic features out of their hat to meet the arbitrary saleslines. (because the answer is usually no)
- If I accept, I would be the sole developer (at first) and responsible for someone else's mountain of nightmarish code, and still responsible for layering on new features at the same pace as he. Pay raise likely, but not guaranteed.
- My getting the position is contingent upon the CEO and the investors, meaning it's by no means guaranteed.
- If I don't accept, likely API Guy will be replaced with someone else of unknown ability, who doesn't know the code, and whom I must answer to regardless. Potentially OK, potentially a monumental disaster.

Honestly, it feels like I'm going to be screwed no matter what course I choose.

Perhaps accepting is slightly better?

The best would be to assume the position of CTO and keep API Guy around -- but that would feel like an insult to him. I doubt he'd be okay with it. But maybe. Who knows? I doubt the CEO would seriously consider that anyway.

I feel like a lamb between a dim, angry rhino, and an oblivious one.

Honestly? People. For the first two years of my career I worked for an investment bank.. Basically working to make rich people richer. That, plus the technology sucked, made me change what I do.

I now work for a company that, while it doesn't cure cancer, it makes products that my friends use, my family uses, even my 1 year old son uses. And knowing I am making a difference in their life in even just a little way is worth it.

Also now that I have a family and a kid, my priorities have shifted and as much as I love coding, my family and kid will always come first now. Could I be making more at an investment bank where I worked 12 hour shifts every day? Sure. But it's not worth it to me.

!rant

Upper management finally caved in to the endless change requests from business and explicitly made the following statement:

"We won't overpromise and under-deliver. With that, we are reducing the committed scope of development work per sprint, but will continue to deliver the same final deliverables by the delivery dates"

So all our compressed project timetables just got uncompressed, and we finally have the breathing room we've been begging for since 2017. Any change requests from business will be (finally) backlogged.

On the other hand, the number of projects have increased to fill out the new extra dev time, but at least we're now less stressed at work. Priorities!

Github 101 (many of these things pertain to other places, but Github is what I'll focus on)

- Even the best still get their shit closed - PRs, issues, whatever. It's a part of the process; learn from it and move on.

- Not every maintainer is nice. Not every maintainer wants X feature. Not every maintainer will give you the time of day. You will never change this, so don't take it personally.

- Asking questions is okay. The trackers aren't just for bug reports/feature requests/PRs. Some maintainers will point you toward StackOverflow but that's usually code for "I don't have time to help you", not "you did something wrong".

- If you open an issue (or ask a question) and it receives a response and then it's closed, don't be upset - that's just how that works. An open issue means something actionable can still happen. If your question has been answered or issue has been resolved, the issue being closed helps maintainers keep things un-cluttered. It's not a middle finger to the face.

- Further, on especially noisy or popular repositories, locking the issue might happen when it's closed. Again, while it might feel like it, it's not a middle finger. It just prevents certain types of wrongdoing from the less... courteous or common-sense-having users.

- Never assume anything about who you're talking to, ever. Even recently, I made this mistake when correcting someone about calling what I thought was "powerpc" just "power". I told them "hey, it's called powerpc by the way" and they (kindly) let me know it's "power" and why, and also that they're on the Power team. Needless to say, they had the authority in that situation. Some people aren't as nice, but the best way to avoid heated discussion is....

- ... don't assume malice. Often I've come across what I perceived to be a rude or pushy comment. Sometimes, it feels as though the person is demanding something. As a native English speaker, I naturally tried to read between the lines as English speakers love to tuck away hidden meanings and emotions into finely crafted sentences. However, in many cases, it turns out that the other person didn't speak English well enough at all and that the easiest and most accurate way for them to convey something was bluntly and directly in English (since, of course, that's the easiest way). Cultures differ, priorities differ, patience tolerances differ. We're all people after all - so don't assume someone is being mean or is trying to start a fight. Insinuating such might actually make things worse.

- Please, PLEASE, search issues first before you open a new one. Explaining why one of my packages will not be re-written as an ESM module is almost muscle memory at this point.

- If you put in the effort, so will I (as a maintainer). Oftentimes, when you're opening an issue on a repository, the owner hasn't looked at the code in a while. If you give them a lot of hints as to how to solve a problem or answer your question, you're going to make them super, duper happy. Provide stack traces, reproduction cases, links to the source code - even open a PR if you can. I can respond to issues and approve PRs from anywhere, but can't always investigate an issue on a computer as readily. This is especially true when filing bugs - if you don't help me solve it, it simply won't be solved.

- [warning: controversial] Emojis dillute your content. It's not often I see it, but sometimes I see someone use emojis every few words to "accent" the word before it. It's annoying, counterproductive, and makes you look like an idiot. It also makes me want to help you way less.

- Github's code search is awful. If you're really looking for something, clone (--depth=1) the repository into /tmp or something and [rip]grep it yourself. Believe me, it will save you time looking for things that clearly exist but don't show up in the search results (or is buried behind an ocean of test files).

- Thanking a maintainer goes a very long way in making connections, especially when you're interacting somewhat heavily with a repository. It almost never happens and having talked with several very famous OSSers about this in the past it really makes our week when it happens. If you ever feel as though you're being noisy or anxious about interacting with a repository, remember that ending your comment with a quick "btw thanks for a cool repo, it's really helpful" always sets things off on a Good Note.

- If you open an issue or a PR, don't close it if it doesn't receive attention. It's really annoying, causes ambiguity in licensing, and doesn't solve anything. It also makes you look overdramatic. OSS is by and large supported by peoples' free time. Life gets in the way a LOT, especially right now, so it's not unusual for an issue (or even a PR) to go untouched for a few weeks, months, or (in some cases) a year or so. If it's urgent, fork :)

I'll leave it at that. I hear about a lot of people too anxious to contribute or interact on Github, but it really isn't so bad!

Inspired by @NoMad. My philosophy is that technology is a means to and ends. We’re a tool oriented species. As it relates to software and hardware, they should be your means to achieve your ends without you needing to think. Think of riding a bicycle or driving a car. You aren’t particularly conscious of them - you just adjust input based on heuristics and reflex - while your doing the activity.

For a long time Software has been horrendously bad at this. There is almost always some setup involved; you need to front-load a plan to get to your ends. Funny enough we’re in the good days now. In the early days of GUI you did have to switch modes to achieve different things until input peripherals got better.

I’ve been using windows from 95 and to this day, though it’s gotten better it’s not trivial to setup an all in one printer and scan a document - just yesterday I had to walk my mother through it and she’s somewhat proficient. Also when things break it’s usually nightmare to fix, which is why fresh installing it periodically is s meme to this day. MS still goes to great lengths with their UI so that most people can still get most of their daily stuff done without a manual.

I started Linux in University when I was offered an intro course on the shell. I’ve been using it professionally ever since. While it’s good at making you feel powerful, it requires intricate knowledge to achieve most things. Things almost never go smoothly no matter how much practice you have, especially if you need to compile tools from source. It also has very little in the ways of safe guards to prevent you from hurting yourself. Sure you might be able to fix it if you press harder but it’s less stress to just fresh install. There is also nothing, NOTHING more frustrating than following documentation to the T and it just doesn’t work! It is my day job to help companies with exactly this. Can’t really give an honest impression of the GUI ux as the distros have varying schools of thoughts with their desktop environments. Even The popular one Ubuntu did weird things for a while. In my humble opinion, *nix is better at powering the internet than being a home computer your grandma can use.

Now after being in the thick of things, priorities change and you really just want to get things done. In 2015 I made the choice to go Mac. It has been one of my more interesting experiences. Honestly, I wish more distros would adopt its philosophy. Elementary only adopted the dock. It’s just so intuitive. How do you install an application? You tap the installer, a box will pop up then you drag the icon to the application folder (in the same box) boom you are done. No setup wizards. How to uninstall? Drag icon from app folder to trash can. Boom done. How to open your app? Tap launch pad and you see all your apps alphabetically just click the one you want. You can keep your frequent ones on the dock. Settings is just another app in launchpad and everything is well labeled. You can even use your printers scanner without digging through menus. You might have issues with finder if your used to windows though and the approach to maximizing and minimizing windows will also get you for a while.

When my Galaxy 4 died I gave iPhone a chance with the SE. I can tell you that for most use cases, there is no discernible difference between iOS and modern android outside of a few fringe features. What struck me though was the power of an ecosystem. My Mac and iPhone just work well together. If they are on the same network they just sync in the background - you need to opt in. My internet went down, my iMac saw that my iPhone had 4g and gave me the option to connect. One click your up. Similar process with s droid would be multi step. You have airdrop which just allows you to send files to another Apple device near you with a tap without you even caring what mechanism it’s using. After google bricked my onHub router I opted to get Apples airport series. They are mostly interchangeable and your Mac and iOS device have a native way to configure it without you needing to mess with connecting to it yourself and blah. Setup WiFi on one device, all your other Apple devices have it. Lots of other cool stuff happen as you add more Apple devices. My wife now as a MacBook, an IPad s d the IPhone 8. She’s been windows android her life but the transition has been sublime. With family sharing any software purchase works for all of us, and not just apples stuff like iCloud and music, everything.

Hate Apple all you want but they get the core tenet that technology should just work without you thinking. That’s why they are the most valued company in the world

I really want to stress that we should add the ticket for adding the missing test cases in *this* sprint and not postpone it any further.

-- "Isn't there something more important to be added instead?"

There. ALWAYS. Is. Something. MORE. Important. The real problem was that we implement the test cases in the past to begin violating our definition of done. We have to fix and one point and we have to own that decision as nobody else will care about passing tests and test coverage. It's our job to care for that.

Yes, we can instead focus on all the other high-priorities task that should have been done yesterday, yet that won't change the fact that large part our codebase will remain an untested messy blackbox just asking for weird bugs and wild goosechases in the future.

Don't hide behind "high priority tasks". A job is done when it is fucking done and tests are part of that. Hurrying from one important task to the next will just mean we'll never do it. There is no better time than right now.

If code coverage got left behind in the past, then we'll have to suck it up in order to fix it as soon as possible, otherwise we'll just suck forever.

I'm considering quitting a job I started a few weeks ago. I'll probably try to find other work first I suppose.

I'm UK based and this is the 6th programming/DevOps role I've had and I've never seen a team that is so utterly opposed to change. This is the largest company I've worked for in a full time capacity so someone please tell me if I'm going to see the same things at other companies of similar sizes (1000 employees). Or even tell me if I'm just being too opinionated and that I simply have different priorities than others I'm working with. The only upside so far is that at least 90% of the people I've been speaking to are very friendly and aren't outwardly toxic.

My first week, I explained during the daily stand up how I had been updating the readmes of a couple of code bases as I set them up locally, updated docker files to fix a few issues, made missing env files, and I didn't mention that I had also started a soon to be very long list of major problems in the code bases. 30 minutes later I get a call from the team lead saying he'd had complaints from another dev about the changes I'd spoke about making to their work. I was told to stash my changes for a few weeks at least and not to bother committing them.

Since then I've found out that even if I had wanted to, I wouldn't have been allowed to merge in my changes. Sprints are 2 weeks long, and are planned several sprints ahead. Trying to get any tickets planned in so far has been a brick wall, and it's clear management only cares about features.

Weirdly enough but not unsurprisingly I've heard loads of complaints about the slow turn around of the dev team to get out anything, be it bug fixes or features. It's weird because when I pointed out that there's currently no centralised logging or an error management platform like bugsnag, there was zero interest. I wrote a 4 page report on the benefits and how it would help the dev team to get away from fire fighting and these hidden issues they keep running into. But I was told that it would have to be planned for next year's work, as this year everything is already planned and there's no space in the budget for the roughly $20 a month a standard bugsnag plan would take.

The reason I even had time to write up such a report is because I get given work that takes 30 minutes and I'm seemingly expected to take several days to do it. I tried asking for more work at the start but I could tell the lead was busy and was frankly just annoyed that he was having to find me work within the narrow confines of what's planned for the sprint.

So I tried to keep busy with a load of code reviews and writing reports on road mapping out how we could improve various things. It's still not much to do though. And hey when I brought up actually implementing psr12 coding standards, there currently aren't any standards and the code bases even use a mix of spaces and tab indentation in the same file, I seemingly got a positive impression at the only senior developer meeting I've been to so far. However when I wrote up a confluence doc on setting up psr12 code sniffing in the various IDEs everyone uses, and mentioned it in a daily stand up, I once again got kickback and a talking to.

It's pretty clear that they'd like me to sit down, do my assigned work, and otherwise try to look busy. While continuing with their terrible practices.

After today I think I'll have to stop trying to do code reviews too as it's clear they don't actually want code to be reviewed. A junior dev who only started writing code last year had written probably the single worst pull request I've ever seen. However it's still a perfectly reasonable thing, they're junior and that's what code reviews are for. So I went through file by file and gently suggested a cleaner or safer way to achieve things, or in a couple of the worst cases I suggested that they bring up a refactor ticket to be made as the code base was trapping them in shocking practices. I'm talking html in strings being concatenated in a class. Database migrations that use hard coded IDs from production data. Database queries that again quote arbitrary production IDs. A mix of tabs and spaces in the same file. Indentation being way off. Etc, the list goes on.
Well of course I get massive kickback from that too, not just from the team lead who they complained to but the junior was incredibly rude and basically told me to shut up because this was how it was done in this code base. For the last 2 days it's been a bit of a back and forth of me at least trying to get the guy to fix the formatting issues, and my lead has messaged me multiple times asking if it can go through code review to QA yet. I don't know why they even bother with code reviews at this point.

Three weeks of spending at least three hours with my computer everyday, and my back is officially in pain.
Funny how priorities change. Now I really want to invest in a good chair or maybe a beanbag.

Every single morning I despair. I can’t stand this job.
Why pay very highly and get very skilled people to have them working 4 to a support ticket. Doing the most mundane support tickets you have ever seen in your life (mainly updating client contact details)?
And why have such a rigorous recruitment process to get people’s in in the first place?

The company is pissing money away by working like this and all the new starters like me think it’s complete shit.
But the bosses and anyone who’s been here a while think it’s great. Company still is making loads of money so they don’t even care about it.

I’ve never met senior developers who have never worked on a greenfield project in their entire careers until I came here.

I can’t believe how I got suckered into this (was head hunted).

Does anyone have a feel for the UK contracting market right now?

I’m considering the jump but I think I’d have to be looking for remote only contracts because where I live has few opportunities ‘on-site’. Preferably c# / angular.

Is there much competition for roles or is there a shortage of skills in the contractors?

The thought of going into another permanent role that could be as bad as this genuinely keeps me awake at night.
I’m not sure I can go somewhere and then have it in the hands of managers to decide what projects I’m going to do and what tech it will be on.

At any big company there’s going to be tech debt as well as new work. So becoming perm now feels like it’s 50-50 whether or not a new job will just mean being put into legacy stuff for a couple of years or doing something that is actually good.

I’ve been talking various people about roles in government departments (multiple different departments are hiring) and because priorities change none the gov recruiters can guarantee what the work is that they’re recruiting for actually is.
Just that the the big recruitment push is to bring work previously done by consultancies back in house. Presumably because consultancies have been fleecing them.

TL;DR: "Best" job is a dynamic flow, your job or your priorities will change, better to just start.

It depends on your definition of "best": do you mean the job that you think you will enjoy the most? The job that you are the most knowledgeable on? The job that you will have the most upward mobility in terms of opportunity for promotions and salary increases?

All of them at once, i suppose, but you cant have everything at once: my advice would be just start somewhere. Thinking you're going to get your dream job fresh out of college is a bad way to look at the world. The best job may be the best right now, but your priorities will change in life.

The best job today may not be the best tomorrow for a variety of reasons, but if you start somewhere, you will always have the experience generated by your existing occupation to carry you forward and propel you into your next big position.

My team is pretty small right now. It's myself and two other guys. One lead, who's been here for five years. A senior who we brought on 2 weeks ago. And me, a regular app dev. The lead put his two weeks in last week and has been trying to brain dump as much as he can onto us.

I've been building a list of prioritization to compensate for when he leaves based on what he was saying was the most important. This list has gotten pretty massive after reviewing most of the processes in place.

I was hired mainly to quell new requests coming in and not to maintain our systems, so that's what I did. I didn't examine our prod code base too closely. I wish I had. It's in a sorry state. I'm pretty sure I have about 2 years of tech debt for a crew of two guys constantly working on it.

I've been trying to prioritize based on what gets the most bug fixes and change requests. These apps will see the biggest changes and will undergo the most maintenance.

Since I'm just a regular app dev it feels weird trying to come up with this and try to prioritize this and come up with a plan. It feels like someone else should have. If it needs done then I guess it needs done. I need to be able to collaborate and work with my co worker and be able to plan for what projects are coming next.

If anyone has any suggestions to tackle tech debt please make them. Or if there's any help for managing priorities in a different manner that may prove helpful I'm open. Honestly, I don't want to tackle this completely blind, it feels like a lot.