Sales employee Bob wants a clickable blue button.

Bob tells product owner Karen about his unstoppable desire for clickable blue buttons.

Karen assigns points for potential and impact (how much does a blue button improve Bob's life, how many people like Bob desire blue buttons)

Karen asks the button team how hard it is to build a button. The button team compares the request to a reference button they've built before, and gives an ease score, with higher score being easier (inverse of scrum points).

These three scores are combined to give a priority score. The global buttonbacklog is sorted by priority.

Once every two weeks (a "sprint") the button team convenes, uses the ease scores to assign scrum points. Difficult tasks are broken up into smaller tasks, because there is a scrum point upper limit. They use the average of the last 5 sprints to calculate each developer's "velocity".

The sprint is filled with tasks, from the top of the global button backlog, up to the team's capacity as determined by velocity. Approximate due dates are assigned, Bob is a happy Bob.

What if boss Peter runs into the office screaming "OUR IMPORTANT CLIENT WANTS A FUCKING PINK BUTTON WHICH MAKES HEARTS APPEAR"?

Devs tell boss to shut the fuck up and talk to Karen. Karen has a carefully curated list of button building tasks sorted by priority, can sedate boss with valium so he calms the fuck down until he can make a case for the impact and potential of his pink button.

Karen might agree that Peter's pink button gets a higher priority than Bob's blue button.

But devs are nocturnal creatures, easily disturbed when approached by humans, their natural rhythms thrown out of balance.

So the sprint is "locked", and Peter's pink button appears at the top of the global backlog, from where it flows into the next sprint.

On rare occasions a sprint is broken open, for example when Karen realizes that all of the end users will commit suicide if they don't have a pink heart-spawning button.

In such an event, Peter must make Bob happy (because Bob is crying that his blue button is delayed). And Peter must make the button team of devs happy.

This usually leads to a ritual involving chocolate or even hardware gift certificates to restore balance to the dev ecosystem.

Working with different nationalities is interesting, and sometimes kind of bewildering. And tiring.

I've been working with an Indian dev for a little while, and while she's a decent dev, interactions with her sometimes leave me a little puzzled. She glazes over serious topics, totally over-sensationalizes unimportant oddities, has yet to say the word "no," and she refers to the senior devs as (quote) "the legends." Also, when asked a question by her boss, like "Are you familiar with this?" Instead of a simple yes/no answer, she shows off a little. Fair, I do this sometimes too, but it's a regular thing with her. Also, like most Indians I've known and/or worked with, she has a very strict class-and-caste view of the world. It honestly makes me a little uncomfortable with how she views people, like certain people belong in certain boxes, how some boxes (and therefore their contents) are inherently better than others, and how it's difficult or simply impossible to move between boxes. My obviously westerner view of things is that you can pick where you want to be and what you want to do, and all it takes to get there is acquiring the proper skills and putting in the required effort. I see no boxes at all, just a sprawling web of trades/specialities. And those legends she talks about? They're good devs with more knowledge than me, but only one, maybe two of them are better devs. I see them as coworkers and leads, not legends. Legends would be the likes of Ada Lovelace, Dennis Ritchie, Yukihuro Matsumoto, and Satoshi Nakamoto. (Among others, obv.). To call a lead dev a legend is just strange to me, unless they're actually deserving, but we don't work with anyone like Wozniak or Carmack.

Since I'm apparently ranting about her a little, let me continue. She's also extremely difficult to understand. Not because of her words or her accent, but I can't ever figure out what she's trying to get across. The words fit together and make valid sentences, but the sentences don't often make sense with one another, and all put together... I'm just totally lost. To be a math nerd, like the two conversations are skew lines: very similar, but can never intersect. What's more, if I say I don't understand and ask for clarification, she refuses and says she doesn't want to confuse me further, and to just do what I think is best. It's incredibly frustrating.

Specifically, we're trying to split up functionality on a ticket -- she's part of a different dev team (accounting), and really should own the accounting portion since she will be responsible for it, but there's no clear boundary in the codebase. Trying to discuss this has been... difficult.

Anyway.

Sometimes other cultures' world views are just puzzling, or even kind of alien. This Irish/Chinese guy stayed at my parents' house for a week. He had red hair, and his facial features were about 3/4 Chinese. He looked strange and really interesting. I can't really explain it, but interacting with him felt like talking to basically any other guy I've known, except sometimes his mannerisms and behavior were just shockingly strange and unexpected, and he occasionally made so little sense to me that I was really taken aback.

This Chinese manager I had valued appearances and percieved honors more than anything else. He cared about punctuality and attire more than productivity. Instead of giving raises for good work or promotions, he would give fancy new titles and maybe allow you to move your desk somewhere with a better view of your coworkers. Not somewhere nicer; somewhere more prominent. How he made connections between concepts was also very strange, like the Chinese/Irish guy earlier. The site templating system was a "bridge?" Idk? He also talked luck with his investors (who were also Chinese), and they would often take the investment money to the casino to see if luck was in the company's favor. Not even kidding.

Also! the Iranian people I've known. They've shown very little emotion, except occasionally anger. If I tried to appease them, they would spurn and insult me, but if I met their anger, they would immediately return to being calm, and always seemed to respect me more afterward. Again, it's a little puzzling. By contrast, meeting an American's anger often makes them dislike you, and exceeding it tends to begin a rivalry.

It's neat seeing how people of different nationalities have different perspectives and world views and think so very differently. but it can also be a little tiring always having to translate and to switch behavior styles, sometimes even between sentences.

It's also frustrating when we simply cannot communicate despite having a language in common.

Back in my teenage , a friend of mine asked me «Can you make me a software that guesses the result of a football match ?» I said «Sure, but you have to tell me how to calculate the chances of a team»
«Yeah, use the previous performances in the league»
«Ok, but you have to tell me how to calculate the expected result using previous performances» He laughed at me and said «If i knew how to calculate chances of winning/losing, i would not need a software!»
I tried to explain it simply «Computers can execute basic operations like sums or subtractions, and they know how to follow a list of basic instructions to give you a result»
He looked me like «If computers are so stupid like you are telling me now, are we all crazy idiots trying to learn how to use stupid machines??» and stated that i obviously misunderstood the real power of a computer. I walked back home thinking how funny was my friend believing in some kind of magic inside box called pc.

Few years later, i start studying IT at university. In the free time i look for small jobs like website development, small office network setup, pcs repair.
I continue noticing people believing that pcs knows what to do and how to do it.
«You sure I lost my data ? No i didn't do a backup. You sure my pc didn't do a backup ? No i hadn't a backup software»
«Why antivirus asks me what to do with the viruses it found. It should delete them obviously! Change my antivirus, it's too stupid for my pc»
«I want more people finding my business thanks to my website. How I imagine my website ? Yeah it has to be cool and full of cool stuff»

All that boring stories leads to my final question :

is our job dealing with persons who think we are some kind of wizard, well learned about dominating the pc magic ?

Please answer no.Please.

Yesterday I had my performance review discussion with my manager after about 6 months into the job, which is my first dev job. Before this, I had spent about 2 years in a support role after graduation, but always yearned to build something cool and be a full time developer. Hence I had made the lunge in spite of a pay cut into a development role.

For the past 6 months I was asked to develop a bunch of features on top of legacy code which is ~15 years old. I did my best and brought in the best ideas and practices onto the table and delivered on time. The features turned out great. I enjoyed working with the team and the team loved me back!

But at the back of my mind, I was hoping that I would get to work on something new and relevant. To quench this thirst, I used to spend my personal time on side projects.

The managers and the leads who have been observing me all along, told me yesterday that my manager got AMAZINGLY positive feedback from the leads and my teammates (who are like 10 years senior to me). Going forward, I get to work on any CRAZY idea and pick up any technology I like with the goal of revamping our product. Essentially I get to work on my side projects full time as long as it adds value to the company.

Ohhhhhh YEAH!

Wish me luck. 😎

I was recuited to do devops work for a client. The project started in late '14. Until mid '15 I was forced to just sit there and do nothing. And I mean nothing. The ops team needed my help but the project lead didn't allow that (endless discussions). Somewhere around the end of '15 I could start to work and quickly learned that I had to report to two leads that couldn't disagree more on what to do and how to do it. I also learned that the companies mentality is "Clean me but don't get me wet". So the ops team demands a lot but is really uncooperative with everything. So I am currently sitting between three grindstones and everything I do is worthless. Because nobody agrees with anybody and I cannot fulfill my job for which I have been hired: Make ops more efficient because they are drowning in manual work. My job is further complicated by the following facts: This company uses no standard whatsoever but their own. Thru this they have created a Rube-Goldberg-Machine. But they think their system is the greatest in the world and the only one that makes sense. Which makes automation pointless because it is not maintainable. They call it diversity and they say that it is the clear reason why automation is not for them even though they schedule meeting after meeting in which they discuss about how to automate things. But in general they do just block everything useful and sabotage my work. And behind my back they make me the reason for the fail. Every real decision is blocked anyway. Also the ops guys think they are the leetest in the world. And everything they invent is above and beyond. If you ask them why they have over 400 VLANs for example (in a company of unter a thousand employees) they stutter and stumble because they cannot explain their complicated shit. They also change their decisions like underwear. Another really "kewl" thing they just did: They hired a devops engineer and everybody loves him. During the interview he said that he has no prior experience with devops whatsoever and it will take him around six month to get started on the basics of devops. I could go on for hours here about the insanity of this company that in my opinion will cease to exist within the next 5 years, if you ask me.
Long story short I am getting out of there by the end of march and will be on sabbatical shortly after because I am burned out. And I mean burned out. Not like "Oh I am burned out". I mean really burned out, with health problems and everything. Another external guy got out here last month because of the same health conditions.

Team quarterly capacity planning:

- Confluence document created with a big table (+100 rows) by product / business. Each row is something that needs to be worked on for the coming quarter.

- Row 1 could be an Epic with 15 tickets attached. Row 2 could be adding a single log to our analytics. No consistency.

- For each row, we create a separate confluence document with the "technical details". 75% of the time these remain blank. 1% of the time there is something useful, the rest its a slightly longer version of the description from the bigger document.

- Each row gets a high level estimate by the leads. 50% of the time without sufficient background info to actually do get it accurate.

- These are then copied into the teams excel spreadsheet, where it will calculate if we are over/under capacity.

- We will go backwards and forwards between confluence and excel until we are "close enough" to under capacity without being too much.

- Once done, we then need to copy them into the org/division's excel spreadsheet. This document is huge, has every team on it and massive 50pt text saying "Do not put a filter on this document".

- Jira tickets + Epics will now be created for each one, with all the data be copied over by hand, bit by bit, by product. Often missing something.

- Last week, at the end of this process for Q2 (2 weeks late), 6 of the leads were asked to attend a 30 minute meeting to discuss how to group the line items together because we had too many for the bigger excel spreadsheet.

- This morning I was told business weren't happy with one of our decisions to delay one line item. Although they were all top priority (P0), one of them was actually higher than that again (P-1?) and we need to work it back in.

... so back to step 1

- Mid way through Q2, a new document will be created for Q3. Work items that didn't make the cut will be manually copied from one to the other. 50/50 whether anything that didn't get done on time in Q2 will make its way to the Q3 doc.

- "Tech excellence" / "Tech debt" items (unit/UI tests, documentation, logging, performance, stability etc) will never be copied over. Because product doesn't understand them and assumes therefore that they are unimportant.

==================

PS: I'd like to say this was a rare event for Q2, but no. Q4 and Q1 were so bad, we were made assurances from the director of engineering that he would fix this process for Q2. This is the new and improved process (I shit you not) that has resulted in nothing tangible.

At a former job, the company decided to replatform to Salesforce. The entire dev team was laid off. But it would take an outside agency a year to build the Salesforce site. The company wanted the devs to stay for an additional year.

The only severance was something they called a stay bonus. It was 30% of our gross income but it was still contingent on performance. And if they decide to let you go earlier, it gets prorated if you still qualify for the bonus. Not a good deal.

Each month a dev left. By the time I secured a new job and left, all that remained of the dev team was a junior frontend dev and two team leads (one FE and one BE) with no team to lead. Well, there were contractors, but they were only brought on after the Salesforce replatform announcement. I’m pretty sure the company had to hire even more contractors. No idea how much that cost them.

For me, I think it was serendipitous that I gave notice during their busiest time of year. They actually tried asking me to extend my notice. Karma was coming back to bite them. Not just for the Salesforce thing. But also for their lack of support when I was blindly accused of being both insubordinate and incompetent.

First I wanna say how grateful I am that devRant exists, because my friends either don’t understand this vocab or don’t care lol.

Last week I worked on a pretty large ticket, opened a PR with 54 file changes. Just to follow standards I set the PR milestone to a future release version, but the truth is I didn’t care which version this work ended up in— I just needed it to go into the develop branch asap.

Since it was a large PR there was some expected discussion that prolonged its merging, but in the meantime I started a second branch that depended on some of the work from this branch. I set the new branch’s upstream to develop, fully expecting my PR to merge into develop, since that’s what I set the PR base to.

I completed all the work I could in the new branch, and got two colleagues to approve the initial PR so it would be merged into develop, I could add the finishing touch and get this work done seamlessly before the week was over. They approved, it got merged, I pulled develop, and… my work wasn’t there. I went to look at my PR and someone had changed the base branch to a release branch. It was my boss, who thought he was helping. (Our bosses don’t actually work on the same team as us, so he didn’t know. it’s weird. We have leads that keep track of our work instead.)

I messaged him and told him I really needed this in develop, knowing our release branch won’t be in develop for probably another week. I was very annoyed but didn’t wanna make him feel too bad so I said I’d just merge the release branch into my new branch. So many conflicts I couldn’t see straight. His response was “yeah and you’ll probably have a bunch of package manager conflicts too because that’s in that release.” He was right— I have so many package manager conflicts that I can’t even see how many compiler conflicts there are. I considered cherry picking my changes, but the whole reason I set develop as my upstream was to avoid having any conflicts since I’m working in the same functions, and this would create more.

So I could spend the next (?) days making educated guesses on possibly a thousand conflict resolutions, or I can revert my release branch merge and quietly step back and wait for the release branch to be merged into develop.

I’m sure cherry picking is the best option here but I’m genuinely too annoyed lol, and fortunately my team does not care to notice if I step back and work on something else to kill time until it’s fixed automatically. But I’m still in dire need of a rant because my entire plan was ruined by a well-meaning person who messed with my PR without asking, so here is that rant and I thank you for your time.

So recently we re-orged to a product vs engineering (yes, I meant vs, it’s contentious) organizational structure. One of the former dev leads got picked for product and went on this lovely ass-kissing spiel about how great this was in front of our new bosses. The next day(!) he was telling his old team what to do directly to his buddy the scrum master, who works for me and casually mentioned it. How am I supposed to run engineering and deliver if every P.O. can end run around the structure? I hate all this.

Also, if the new PE tells me one more time all my problems can be solved with SQS, I’m gonna explode. Not all dev problems are a nail to fix with an sns hammer. Asynch comms has its uses, it is not the *only solution.

I feel like I’m over reacting, and yet, I still feel rage…and happy to find an anonymous place to rant about it.

➡️You Are Not A Software Developer⬅️

When I became a developer, I thought that my job is to write software. When my customer had a problem, I was ready to write software that solves that problem. I was taught to write software.

But what customers need is not software. They need a solution to their problem. Your job is to find the most cost-effective solution, what software often is not.

According to the universal law of software development, more code leads to more bugs:

e = mc²

Or

errors = (more code)²

The number of bugs grows with the amount of code. You have to prioritize, reproduce and fix bugs.

The more code you write, the more your team and the team after it has to maintain. Even if you split the system into micro services, the complexity remains.

Writing well-tested, clean code takes a lot of time. When you’re writing code, other important work is idle. The work that prevents your company from becoming rich.

A for-profit company wants to make money and reduce expenses. Then the company hires you to solve problems that prevent it from becoming rich. Confused by your job title, you take their money and turn it into expensive software.

But business has nothing to do about software. Even software business is not about software. Business is about making money.

Your job is to understand how the company is making money, help make more money and reduce expenses. Once you know that, you will become the most valuable asset in the company.

Stop viewing yourself as a software developer. You are a money maker.

Think about how to save and make money for your customers.

Find the most annoying problem and fix it:

▶️Is adding a new feature too costly? Solve the problem manually.
▶️Is testing slow? Become a tester.
▶️Is hiring not going well? Speak at a meetup and advertise your company.
▶️Is your team not productive enough? Bring them coffee.

Your job title doesn’t matter. Ego doesn’t matter either.

Titles and roles are distracting us from what matters to our customers – money.💸

You are a money maker. Thinking as a money maker can help choose the next skill for development. For example:

Serverless: pay only for resources you consume, spend less time on capacity planning = 💰

Machine Learning: get rid of manual decision-making = 💰

TDD: shorter feedback cycle, fewer bugs = 💰

Soft Skills: inspire teammates, so they are more productive and happy = 💰

If you don’t know what to learn next — answer a simple question:

What skills can help my company make more money and reduce expenses?

Very unlikely it’s another web framework written in JavaScript.

Article by Eduards Sizovs
Sizovs.net

the fuck kind of manager are you that you tell your leads not to fucking answer their damn phones when services need restoring????? If your fucking team member can do his damn job like a grown ass adult, but sees that you (his lead) made a change and has questions, your ass better answer the phone, or i will rocket launch it up your ass, straight into your brain so it's the newest, latest, fucking hippest trend and hooked into your system so you answer every fucking call hands-free. Even when fucking "Windows Tech Support" calls you every 30 minutes because your keep expired.

There are people counting on you, worthless fuckwipe. Get. The. Fuck. Over. Yourself. And do your fucking job.

Edit: phone tried to censor me

Biggest challenge I overcame as dev? One of many.

Avoiding a life sentence when the 'powers that be' targeted one of my libraries for the root cause of system performance issues and I didn't correct that accusation with a flame thrower.

What the accusation? What I named the library. Yep. The *name* was causing every single problem in the system.

Panorama (very, very expensive APM system at the time) identified my library in it's analysis, the calls to/from SQLServer was the bottleneck

We had one of Panorama's engineers on-site and he asked what (not the actual name) MyLibrary was and (I'll preface I did not know or involved in any of the so-called 'research') a crack team of developers+managers researched the system thoroughly and found MyLibrary was used in just about every project. I wrote the .Net 1.1 MyLibrary as a mini-ORM to simplify the execution of database code (stored procs, etc) and gracefully handle+log database exceptions (auto-logged details such as the target db, stored procedure name, parameter values, etc, everything you'd need to troubleshoot database errors). This was before Dapper and the other fancy tools used by kids these days.

By the time the news got to me, there was a team cobbled together who's only focus was to remove any/every trace of MyLibrary from the code base. Using Waterfall, they calculated it would take at least a year to remove+replace MyLibrary with the equivalent ADO.Net plumbing.

In a department wide meeting:

DeptMgr: "This day forward, no one is to use MyLibrary to access the database! It's slow, unprofessionally named, and the root cause of all the database issues."
Me: "What about MyLibrary is slow? It's excecuting standard the ADO.Net code. Only extra bit of code is the exception handling to capture the details when the exception is logged."
DeptMgr: "We've spent the last 6 weeks with the Panorama engineer and he's identified MyLibrary as the cause. Company has spent over $100,000 on this software and we have to make fact based decisions. Look at this slide ... "
<DeptMgr shows a histogram of the stacktrace, showing MyLibrary as the slowest>
Me: "You do realize that the execution time is the database call itself, not the code. In that example, the invoice call, it's the stored procedure that taking 5 seconds, not MyLibrary."
<at this point, DeptMgr is getting red-face mad>
AreaMgr: "Yes...yes...but if we stopped using MyLibrary, removing the unnecessary layers, will make the code run faster."
<typical headknodd-ers knod their heads in agreement>
Dev01: "The loading of MyLibrary takes CPU cycles away from code that supports our customers. Every CPU cycle counts."
<headknod-ding continues>
Me: "I'm really confused. Maybe I'm looking at the data wrong. On the slide where you highlighted all the bottlenecks, the histogram shows the latency is the database, I mean...it's right there, in red. Am I looking at it wrong?"
<this was meeting with 20+ other devs, mgrs, a VP, the Panorama engineer>
DeptMgr: "Yes you are! I know MyLibrary is your baby. You need to check your ego at the door and face the facts. Your MyLibrary is a failed experiment and needs to be exterminated from this system!"

Fast forward 9 months, maybe 50% of the projects updated, come across the documentation left from the Panorama. Even after the removal of MyLibrary, there was zero increases in performance. The engineer recommended DBAs start optimizing their indexes and other N+1 problems discovered. I decide to ask the developer who lead the re-write.

Me: "I see that removing MyLibrary did nothing to improve performance."
Dev: "Yes, DeptMgr was pissed. He was ready to throw the Panorama engineer out a window when he said the problems were in the database all along. Didn't you say that?"
Me: "Um, so is this re-write project dead?"
Dev: "No. Removing MyLibrary introduced all kinds of bugs. All the boilerplate ADO.Net code caused a lot of unhandled exceptions, then we had to go back and write exception handling code."
Me: "What a failure. What dipshit would think writing more code leads to less bugs?"
Dev: "I know, I know. We're so far behind schedule. We had to come up with something. I ended up writing a library to make replacing MyLibrary easier. I called it KnightRider. Like the TV show. Everyone is excited to speed up their code with KnightRider. Same method names, same exception handling. All we have to do is replace MyLibrary with KnightRider and we're done."
Me: "Won't the bottlenecks then point to KnightRider?"
Dev: "Meh, not my problem. Panorama meets primarily with the DBAs and the networking team now. I doubt we ever use Panorama to look at our C# code."

Needless to say, I was (still) pissed that they had used MyLibrary as dirty word and a scapegoat for months when they *knew* where the problems were. Pissed enough for a flamethrower? Maybe.

Team leads be like

I'm task to amend the code smell in the project. I literally can cry a river.
I see such thing as i = i++; - It's flag out as a bug.

I have also seen check in classes. With un-used variables. I literally cried.

In the past, i ask why do i got to care about code quality. I actually start to get angry like the team leads in my project.

Argh,

Today - you son of a bitch.

It all started with a 2 hour flight out of town for business, and I mean started as in I needed to be at the airport at 4:30am!

Despite 2 coffee's to get me out of bed I proceeded to indulge myself in the magic juice, 3 cups later and it felt like my heart belonged in a Grand Prix.

Now here is the sticky part, we where briefed that we would only be doing 2 site meetings and that was it.

Low and be hold it got worse, turns out that we would be pitching our product to 3 highly regarded CEO's, now bare in mind that my position on this trip is as the lead developer, and don't get me wrong I am well up to date on every aspect of the business, hence why they sent me.

So more coffee down the gullet, and eventually the conversation leads back to a project that I had developed to allow authorization of debit orders online, now usually I'm quite a well presented person in these types of situations, but you don't realize how quick this can change.

A quick jump to the geography of the location I was doing business. Johannesburg, South Africa - its as dry as hell, smoggy and at a very higher altitude "as in above sea level".

Now unfortunately none of the above factors where helping me much at all.

Now back to where I am being asked about my project, and never in my life have I tripped over my own words, I went completely blank, I'm surprised I didn't pass out to be honest.

Now despite the death stare and my colleague kicking me under the table, I am feeling pretty terrible, fortunately I had a kick ass team that was able to cover my ass!

Luckily I was able to recover ( 2 muffins and about 3 bottles of water later). We where able to salvage the meeting and it turned out pretty well, I regained my energy and we made it happen!

Must say the flight back was amazing! Almost empty and we all had a row of seats to ourselves, which resulted in some major comfort stretching!

Thanks for tolerating my essay, I'd love to hear if anyone has had anything of the sorts happen to them.

So we have this one dude in our team. Mid level engineer. 7 months old in the company. Arguing with everyone. Doesn't listen to the leads. Wants to do stuff in his own way. Complains about everything. First I thought he knows he stuff. But the. I realized he just wants to disagree with everything. Also thinks that all the work he did in his last job is superior. But most of the things are not following standards. Looks like he is just full of himself. How to deal with a person like that? Will he get fired eventually?

I'm sick to death of hiring people from other companies and explaining GitFlow and why its useful (what are you people doing?).

Then watching them doing it wrong, pointing out its easier to use something like sourcetree. Which leads to "... well see, the terminal is just more efficient, tools like sourcetree are bloated".

Ok fair enough, well heres the deal i'll make with you, while using your "efficient tool", stop breaking our workflow and i'm fine for you to keep using it. Otherwise, stop being a dick and be a team player.

IF YOU UPDATE AN ADM PLATTFORM FOR FUCKS SAKE DON'T DO THE FOLLOWING THINGS:

1. ONLY DOCUMENTATE IT IN A POWERPOINT

2. WRITE DOWN IPs AND PORTS ONLY ON A WHITE-BORD

3. MOVE TOOLS TO OTHER SUBNETS OR DOMAINS WITHOUT PROPERLY KNOWING THE WAYS OF COMMUNICATION BETWEEN THEM

4. USE YOUR PERSONAL EMAIL ADDRESS AS RESET OPTION FOR LICENCE-MANAGEMENT ACCESS IF NO ONE KNOWS THE PW

5. LEAVE THE COMPANY THE DAY AFTER THE UPGRADE IS DONE

Because the guy who has to take care of the upcoming problems is not going to like you!

BUT having to deal with all of this at once would not be a problem if your, so called team (30 People who work with those applications e.g. as test-engineers) would actually work together instead of having that "not my daily business, I am going to drink coffee" attitude.

Apparently I am the only one who has enough balls to see, admit, and report a problem to our leadership.
This always leads to Me fixing the issue...
....that's alright I am learning a lot...
...BUT IF A TEAM-MATE, WHO HAS THE SAME DEGREE AS I AM GOING TO GET, LEAVES EARY BECAUSE: "HE DOES NOT KNOW WHATS WRONG", IT TRIGGERS ME!!!

- The apprenticeship guy

PS Needless to say hundreds of clients have access to those systems and I worked through a shittload of official tool docs just to get to know the tools first...

tl;dr - My company makes me pass around code over email. Is this normal?

How we fix bugs at my company.
1. Simulate bug in dev env (ok, cool)
2. Get the required code from svn and make changes locally (so far, so good)
3. Deploy changes in dev env and test (yeah!)
4. Take screenshots of fix in action along with the files you've changed and mail it to the respective leads (really? send code via mail?)
5. Keep changing your fix based on feedback and keep repeating above steps (what!)
6. Once approval mail comes, check-in your code in the svn branch for deployment and testing in the test env (QA team)

My question to you fine folks is, is this normal? Is this how most companies work? Passing around code over e-mail? Where the different versions of your fix are just attachments in emails. Or have I committed a sin by being a part of this heinous act?

I feel like resigning from a company that i joined 3 weeks back.

I don't like to code in PHP and the manager wants to stick on to that , no new developers joining the company and php is one of the reason. The code is a mess. Every now and then some other team come running for a change like one button to do some shit and then for a fix after 15mins of release.

So many database operations are happening manually. No innovation in the team. Developers are very boring , women being senior developers and team leads brings stability but there is no innovation , excitement or any enthusiasm. All my team members are very happy doing mediocre shit. Manager talks about agile development and they are following that at a level where every half a day some requirement changes.

I m tired of being a developer that fixes the same mediocre shit.

Its too boring.

Got demoted, got a pay raise and don't know how to feel about it. A story of how not to drink with your coworkers?

The story begins roughly 8-9 months ago. Me and this coworker (let's name him Tim) go out drinking after a Friday party at the office. We do some rounds and we're both smashed. Tim starts telling me how he's happy with life and that he's earning a nice salary right now. He told me his salary. It was the same as mine. Which was weird - He codes in a more hardcore languages than me and has almost double the time in the company as me. I think after some more drinking I've confessed that I make the same as him. This part is sort of a blur (drinking). I've gotten a pay raise(+30-40%) roughly a few months ago from that point backwards because another company gave be a much higher offer. The company I work for matched to keep me. Anyway, 3 months or so after the drinking,Tim is promoted to team lead, and me and a few other people are added to his team. Conversation slips and he told me his new salary - quite a bit more than me.I think it's safe to assume what happened.

The problem with that is that I was a team lead of 1 person (me) at that time, and I was managing my own time and my own tasks, was working with people individually. I was part of the weekly meetings with the CEO and other team leads. Being stripped of this title wasn't a problem at the beginning, as people still contacted me because of their problems, suggestions, whatever. A few more months pass (to now) and less and less people are contacting me - instead they are talking with Tim, and are asking of his opinion on tasks I should do, where he has no experience and roughly 0 lines in the programming language I code in. This is starting to piss me off.

There are a couple other things to take into consideration as well - The company is hiring a lot of people right now. The whole structure for team leads changed a bit, more team leads then ever right now and new roles added pretty fast.

I've gotten a pay raise a few weeks ago though(10%~).

I'm not sure on how to react to this. Should I comply and just keep on working on these tasks? Or should I still keep contacting people directly on their requests and talk to them directly, take credit for the projects I complete publicly and the stuff I do as I was previously doing? Part of me wants to reroute all of the stupids questions people have to Tim, as he is now responsible for these tasks and get this weight off my shoulders.

I'm starting to shift to learning a new programming language and thinking of jumping ship. Thoughts?

what an absolute condescending garbage post...

"brilliant coder who can't meet a deadline"? well, you're the idiot right there, you just admitted it - they are brilliant and you don't know how to set deadlines

imagine labeling someone who can't meet a workload DIFFICULT! god this is making me fucking fume

"normal management" - yeah this is normal management alright, treating everyone like they don't know what they are doing and expecting them to follow you blindly, sounds pretty normal to me

it's shit like this that leads to cocky ass young dumb managers who actually don't know shit about building a product themselves, but then turn around and think they instead have the ability to manage a team to do it... incredible

So apparently the CIO knows all about my team lead sucking it up as a boss, and is letting him do it. He's constantly on the team leads ass about stuff and it's stressing him out.

The CIO wants him to stop being so micro managey and let the team handle things... But instead of telling the team lead that, he'd rather just blast him constantly and stress him out which makes it roll onto us and stress the whole team out.

I wish the CIO would just tell him to square up or just fire him... This stress isn't good for anyone.

dev, ~boring

This is either a shower thought or a sober weed thought, not really sure which, but I've given some serious consideration to "team composition" and "working condition" as a facet of employment, particularly in regard to how they translate into hiring decisions and team composition.

I've put together a number of teams over the years, and in almost every case I've had to abide by an assemblage of pre-defined contexts that dictated the terms of the team working arrangement:

1. a team structure dictated to me
2. a working temporality scheme dictated to me
3. a geographic region in which I was allowed to hire
4. a headcount, position tuple I was required to abide by

I've come to regard these structures as weaknesses. It's a bit like the project management triangle in which you choose 1-2 from a list of inadequate options. Sometimes this is grounded in business reality, but more often than not it's because the people surrounding the decisions thrive on risk mitigation frameworks that become trickle down failure as they impose themselves on all aspects of the business regardless of compatibility.

At the moment, I'm in another startup that I have significantly more control over and again have found my partners discussing the imposition of structure and framework around how, where, why, who and what work people do before contact with any action. My mind is screaming at me to pull the cord, as much as I hate the expression. This stems from a single thought:

"Hierarchy and structure should arise from an understanding of a problem domain"

As engineers we develop processes based on logic; it's our job, it's what we do. Logic operates on data derived from from experiments, so in the absence of the real we perform thought experiments that attempt to reveal some fundamental fact we can use to make a determination.

In this instance we can ask ourselves the question, "what works?" The question can have a number contexts: people, effort required, time, pay, need, skills, regulation, schedule. These things in isolation all have a relative importance ( a weight ), and they can relatively expose limits of mutual exclusivity (pay > budget, skills < need, schedule < (people * time/effort)). The pre-imposed frameworks in that light are just generic attempts to abstract away those concerns based on pre-existing knowledge. There's a chance they're fine, and just generally misunderstood or misapplied; there's also a chance they're insufficient in the face of change.

Fictional entities like the "A Team," comprise a group of humans whose skills are mutually compatible, and achieve synergy by random chance. Since real life doesn't work on movie/comic book logic, it's easy to dismiss the seed of possibility there, that an organic structure can naturally evolve to function beyond its basic parts due to a natural compatibility that wasn't necessarily statistically quantifiable (par-entropic).

I'm definitely not proposing that, nor do I subscribe to the 10x ninja founders are ideal theory. Moreso, this line of reasoning leads me to the thought that team composition can be grown organically based on an acceptance of a few observed truths about shipping products:

1. demand is constant
2. skills can either be bought or developed
3. the requirement for skills grows linearly
4. hierarchy limits the potential for flexibility
5. a team's technically proficiency over time should lead to a non-linear relationship relationship between headcount and growth

Given that, I can devise a heuristic, organic framework for growing a team:

- Don't impose reporting structure before it has value (you don't have to flatten a hierarchy that doesn't exist)
- crush silos before they arise
- Identify needed skills based on objectives
- base salary projections on need, not available capital
- Hire to fill skills gap, be open to training since you have to pay for it either way
- Timelines should always account for skills gap and training efforts
- Assume churn will happen based on team dynamics
- Where someone is doesn't matter so long as it's legal. Time zones are only a problem if you make them one.
- Understand that the needs of a team are relative to a given project, so cookie cutter team composition and project management won't work in software
- Accept that failure is always a risk
- operate with the assumption that teams that are skilled, empowered and motivated are more likely to succeed.
- Culture fit is a per team thing, if the team hates each other they won't work well no matter how much time and money you throw at it

Last thing isn't derived from the train of thought, just things I feel are true:

- Training and headcount is an investment that grows linearly over time, but can have exponential value. Retain people, not services.
- "you build it, you run it" will result in happier customers, faster pivoting. Don't adopt an application maintenance strategy

/rant

Being a team leader some times sucks have to take responsibility for everyone's elses functionality that doesn't work or wasn't tested in production. Leads often ends up working overtime fixing everyone elses work :(

So, rant!

So, global-huge-paradigm-shift project moving forward. Lots and lots of architects of multiple sites world-wide, stakeholders and business peeps and sub-corp manager and head-of-fucking-everything-of-multi-billion-dollar-CEO involved with different amounts of energy and passion.

Huge amount of money involved. Not only for the multi-year project endeavour but also in licensing costs for the years and years to come.

It's a big deal for the corporation.

And it's clowns everywhere. Leadership, project leads, technical project leads, architects. Am I one of them? I don't think so because everyone is mad at me. Since I cause trouble. Since I tend to say that I don't give a FUCK about the product being a Gartner Visionary player if you can't test the fucker properly...

Last week I attended a workshop in USA (I live in Europe) regarding this change which left me with a bad taste in my mouth. I am so far away from my comfort zone.

To these people (me?) get payed for this work? Is this really relevant? Why the FUCK did I need to go to a different continent? "The "Core team" need to be on site". Yeah, right. Fuck you Mr Project Leader, I can tell you are far, far away of being on-top of this thing...

Pointless.

It's pointless.

But I guess this is why you get payed.

Work.

Tomorrow is Tuesday and I think I will raise my hand yet again and explain to all I meet that I see HUGE risks with this project as it goes along right now. We kind of make things and that has to, you know, work. NOT making things for 1 hour is... well, that is really, really bad.

I give this project ten percent chance of succeeding above the set thresholds for all different areas/functionality. (I am sure the fuckers will alter the thresholds to show off a "successful project". Fuckers.

I just found out last Friday that my team collegues (all of them are team leads) are suffering from depression or the so called burn out syndrom. I guess it's my boss' fault. He never gives clear jobs, changes his mind from day to day, we have to manage unclear responsibilities and the baddest thing is that we think that our boss is too stressed out himself.

Do you have any advice for me how we as team could solve that besides changing employer? One thing to mention is, that my boss likes to hear himself talking. That makes it even harder for a guy like myself who is more or less introverted to come up with good arguments which are not overheard or overtalked immediately. What are your feedback strategies to your own boss, how do you bring such stuff on the table?

I fear that when nothing happens, my company will suffer very hard when the whole product engineering departement will fall apart (¼ of the whole company and is responsible for engineering and maintaining of internal services and managed services for our customers).

Well at least it was worth writing about it, maybe my subconcious mind will come up with a brilliant idea itself in the near future in some asynchronous way. But you might be the one with that valuable input, then don't hesitate to share, it will be welcome.

My company is (supposedly) all about collaborative work, pair programming, getting on calls and cRaCKinG tHinGs ToGEtheR. Also (and rightfully so) we’re not supposed to approve any PRs if tests weren’t created/updated.
Of course that applies to all but the old timers in the company who simply act like lone cowboys. They fall off the face of the earth for two-three days then reappear with monster PRs full of untested code.

Leave it up to the plebe then to try to make sense of the mess they’ve created, to challenge them with the fact that the PRs are lacking tests (only to be met with excuses about not having anymore time to spend on the subject).
Reprimand the plebe for not reviewing PRs thoroughly enough. Leave it up to them to fix the resulting bugs.

I’ve lost all trust in our managers, tech leads, lead devs and their guidelines and rules that only apply to others but rarely to themselves. These people that then have the audacity to criticize the tech team in it’s entirety for not being rigorous enough in its processes.
Fuck them all

About a year ago, the organization I work for decided we don't really need team leads. We would be more self organizing if we didn't have technical leads. Now, one of those former leads who feels out of place can't get over it. She is constantly trying to add her two cents -- which is totally cool -- but in such a way as to make it sound/seem like we need to do what she says. Also, based on everything I've seen from her coding ability, I'm not sure how she ever became a tech lead. That's coming from me, and let me tell you, I feel SUPER junior sometimes. Like how the hell did they ever offer me a job junior. Well anyway, another dude was working with her the other day (we do pair programming) and snapped. He flipped out for like a solid 3 minutes on her. It was the most awkward thing I think I've ever experienced.

I've been sort of lost after New Year's...

Last few years, my main goal was just to learn stuff to pass technical interviews. I also did a lot of personal dev in C#... and played with the js, python, and when a bit of c++.

But this year I kinda feel sorta of "ah screw it". Interviews never work out, haven't for years, what's the point in even trying... I get paid enough though the work is sort boring and team sort of feels like the Wild West, no rules, code reviews, processes...

But ¯\_(ツ)_/¯

Feels like coding has lost its place at the top now. The future is all cloud, machine learning, big data/real time analytics but feels like these are out of reach for just 1 guy...

And well doesn't seem like anyone is going to give me a job because I'm not a good fit or have enough experience in these areas...

Sorta lost now but guess this is what a sudden thought leads to...

Oh and maybe just with tech in general. It feels this year I'm just not as interested as I was before... Spent a lot of time binge watching movies and stuff instead....

Yea...I built the system. That doesn't mean I want to spend all day using it to perform administrative tasks for you and your team. I only have permissions to do things because it's the nature of the beast...not because I should be assigning leads, granting permissions, etc. Please! Someone take the reins and use the shit I built!

Why team leads assume that because the designer took 10 minutes to adjust a form, it means it will take me also 10 minutes to adjust the code?

Especially if I just strated working with the theme. And I told them I'm a backend developer who did little work with theming....

So how do team leads get away with saying "Hol' up, I ain't technical" when you try to explain something?

The company that I work for just opted for PHP in favor of Elixir, Node and Scala(Akka really) for building a high-concurrency system, because we have more people who work with PHP (mediocre skill really). How do we convince our team leads and higher-order beings by the hierarchy to try newer (or at least better suited) technologies? Good luck popening and pthreading stuff on this project I guess.

Why would companies ever hire a manager from a non-tech background, at least for managing engineers? After reading @IAmNotARobot's latest rant I just have to ask because it makes absolutely no sense to me. Surely non-tech people should be reserved for managing non-tech roles like sales, HR, and maaaaybe team leads, right? How can you manage someone if you don't understand anything of what they do?

Just my luck that I get the best wk76 story ever on wk77. Either way:

So some of you may know that the current project I am on has some shared code components with one of the other projects in the product line. And we have some differences in our processes. This leads to a lot of fun.

So, I was working on converting one of our shared components into a more modern language. It would save us time, money, and sanity by allowing us to more easily maintain our product. Sounds like a win-win right? That's what I thought. Until I had a meeting with the other team. THEN THE QUESTIONS ROLLED IN. Well who is going to integrate our product with yours? (You?) Are you changing the interface? (Not really.) Are you going to generate a design document? (Absolutely not especially since the interface isn't changing for the most part.) Well you are changing the type of one parameter in one method from an undocumented unmanaged type to a well documented managed type that we control. Shouldn't you generate a document to document that change? (Again absolutely not.)

So first they basically browbeat my lead into putting me in charge of their integration effort. Its fine though, as they gave me an account to charge. However, when I was finally able to get a machine with their build environment on it (at least two months later), they then told me that that account was closing and I had to wait until next quarter. So fuck me right. And because of their process I would break them if I were to check my changes in.

So fast forward to today. They are translating some shared components for the same reason that we are. However, they are changing code that while shared is technically "ours" and that will DEFINITELY break us if they do this work since this is the code that controls our algorithms. And while we have a fault tolerant process, or at least more fault tolerant than the other group's, we are currently doing a huge amount of development in the part they want to change. And when we ask them "who is going to do this work to integrate our product with your changes?" they stare at us slack jawed. Like "um, you right? it doesn't affect us." Like MOTHERFUCKERS!!! YOU LITERALLY JUST FOIST ALL THIS WORK ON US TO INTEGRATE WITH YOU BECAUSE YOU DIDN'T HAVE THE PEOPLE TO SUPPORT IT!!! BUT YOU CAN PAY THIS GUY FOR SIX MONTHS TO DO ALL THIS WORK THAT WILL BREAK US BUT CAN'T SPARE HIM TO INTEGRATE WITH US!?!?!? EVEN IF WE'RE PAYING HIM AND NOT YOU!?!?!

I will let you know how this goes when we have the discussion. I am drinking right now because it it easier and better for my emotional and physical health than bum fights.

The worst part of being a dev? Working in teams.

And I don't mean that in the "I'm the best ninja code wizard in the whole world and you're all holding me back" kinda way. I'm thinking more in the lines of someone who has to deal with that kind of attitude on a daily basis. As someone who recently was put in a leading position in a dev team, this is by far one of the worst experiences that came with it.

Some examples?
- One dev completely changed the naming scheme for variables in a class he worked on for one. single. bug fix. His reason? He just didn't like it!
- Another one noticed that data he was supplied with was not in the specified format. Instead of flagging this with the project leads, he just rewrote his parser to fit the data. A couple of weeks later the supplier noticed the error, fixed the format and suddenly everyone wondered why the software failed processing the data.
- Or that one senior dev, that just refuses to accept changes because "it was always done like this and it worked" No, it didn't. That's why it was changed!

Once a dev team reaches a certain size, people need to realize that stuff like coding rules and process guidelines are not there to annoy them but to help the whole team work as efficient as possible. I don't care how good a programmer you are, if you can't check your ego you don't belong in any kind of team-oriented development project!

You know what? FUCK Australian employers. I know they'd be damn fucking lucky to have me on their team.

I just finished working on something that I made several years ago (what I raised funds for in my previous rant), I then took it a step further and automated the process [if some things], and now I have my own software finding me new leads and sending them to me via email and push notifications.

With a little bit of tweaking maybe, and a little bit of time, I expect to find some new clients again.

Why don't managers/team-leads take into account the time that you get stuck on something that's stupid to ask but it eats up your hours :(

A tale of silos, pivots, and mismanagement.

Background: Our consultancy has been working with this client for over a year now. It started with some of our back-end devs working on the API.

We are in Canada. The client is located in the US. There are two other teams in Canada. The client has an overseas company contracted to do the front-end of the app. And at the time we started, there was a 'UX consultancy' also in the US.

I joined the project several months in to replace the then-defunct UX company. I was the only UX consultant on the project at that time. I was also to build out a functional front-end 'prototype' (Vue/Scss) ahead of the other teams so that we could begin tying the fractured arms of the product together.

At this point there was a partial spec for the back-end, a somewhat architected API, a loose idea of a basic front-end, and a smattering of ideas, concepts, sketches, and horrific wireframes scattered about various places online.

At this point we had:
One back-end
One front-end
One functional prototype
One back-end Jira board
One front-end Jira board
No task-management for UX

You might get where this is going...

None of the teams had shared meetings. None of the team leads spoke to each other. Each team had their own terms, their own trajectory, and their own goals.

Just as our team started pushing for more alignment, and we began having shared meetings, the client decided to pivot the product in another direction.

Now we had:
One back-end
One original front-end
One first-pivot front-end
Two functional prototypes
One front-end Jira board
One back-end Jira board

No worries. We're professionals. We do this all the time. We rolled with it and we shifted focus to a new direction, with the same goals in mind internally to keep things aligned and moving along.

Slowly, the client hired managers to start leading everything in the same direction. Things started to look up. The back-end team and the product and UX teams started aligning goals and working toward the same objectives.

Then the client shifted directions again. This time bigger. More 'verticals'. I was to leave the previous 'prototypes' behind, and feature-freeze them to work on the new direction.

One back-end
One conceptual 'new' back-end
One original front-end
One first-pivot front-end
One 'all verticals' front-end
One functional prototype
One back-end Jira board
One front-end Jira board
One product Jira board
One UX Jira board

Meanwhile, the back-end team, the front-end team overseas, all kept moving in the previously agreed-upon direction.

At this stage, probably 6 months in, the 'prototypes' were much less proper 'prototypes' but actually just full apps (with a stubbed back-end since I was never given permission or support to access the actual back-end).

The state of things today:
Back to one back-end
One original front-end
One first-pivot front-end
One 'all verticals' front-end
One 'working' front-end
One 'QA' front-end
One 'demo' front-end
One functional prototype
One back-end Jira board
Two front-end Jira boards
One current product Jira board
One future product Jira board
One current UX Jira board
One future UX Jira board
One QA Jira board

I report to approximately 4 people remotely (depending on the task or the week).

There are three representatives from 'product' who dictate features and priorities (they often do not align).

I still maintain the 'prototype' to this day. The front-end team does not have access to the code of this 'prototype' (the clients' request). The client's QA team does not test against the 'prototype'.

The demos of the front-end version of the product include peanut-gallery design-by-committee 'bug call-outs', feature requests, and scope creep by attendees in the dozens from all manner of teams and directors.

This started as an update to my cover story for my Linked In profile, but as I got into a groove writing it, it turned into something more, but I’m not really sure what exactly. It maybe gets a little preachy towards the end so I’m not sure if I want to use it on LI but I figure it might be appreciated here:

In my IT career of nearly 20 years, I have worked on a very wide range of projects. I have worked on everything from mobile apps (both Adroid and iOS) to eCommerce to document management to CMS. I have such a broad technical background that if I am unfamiliar with any technology, there is a very good chance I can pick it up and run with it in a very short timespan.

If you think of the value that team members add to the team as a whole in mathematical terms, you have adders and you have subtractors. I am neither. I am a multiplier. I enjoy coaching, leading and architecture, but I don’t ever want to get out of the code entirely.

For the last 9 years, I have functioned as a technical team lead on a variety of highly successful and highly productive teams. As far as team leads go, I tend to be a bit more hands on. Generally, I manage to actively develop code about 25% of the time to keep my skills sharp and have a clear understanding of my team’s codebase.

Beyond that I also like to review as much of the code coming into the codebase as practical. I do this for 3 reasons. I do this because as a team lead, I am ultimately the one responsible for the quality and stability of the codebase. This also allows me to keep a finger on the pulse of the team, so that I have a better idea of who is struggling and who is outperforming. Finally, I recognize that my way may not necessarily be the best way to do something and I am perfectly willing to admit the same. I have learned just as much if not more by reviewing the work of others than having someone else review my own.

It has been said that if you find a job you love, you’ll never work a day in your life. This describes my relationship with software development perfectly. I have known that I would be writing software in some capacity for a living since I wrote my first “hello world” program in BASIC in the third grade.

I don’t like the term programmer because it has a sense of impersonality to it. I tolerate the title Software Developer, because it’s the industry standard. Personally, I prefer Software Craftsman to any other current vernacular for those that sling code for a living.

All too often is our work compiled into binary form, both literally and figuratively. Our users take for granted the fact that an app “just works”, without thinking about the proper use of layers of abstraction and separation of concerns, Gang of Four design patterns or why an abstract class was used instead of an interface. Take a look at any mediocre app’s review distribution in the App Store. You will inevitably see an inverse bell curve. Lot’s of 4’s and 5’s and lots of (but hopefully not as many) 1’s and not much in the middle. This leads one to believe that even given the subjective nature of a 5 star scale, users still look at things in terms of either “this app works for me” or “this one doesn’t”. It’s all still 1’s and 0’s.

Even as a contributor to many open source projects myself, I’ll be the first to admit that have never sat down and cracked open the Spring Framework to truly appreciate the work that has been poured into it. Yet, when I’m in backend mode, I’m working with Spring nearly every single day.

The moniker Software Craftsman helps to convey the fact that I put my heart and soul into every line of code that I or a member of my team write. An API contract isn’t just well designed or not. Some are better designed than others. Some are better documented than others. Despite the fact that the end result of our work is literally just a bunch of 1’s and 0’s, computer science is not an exact science at all. Anyone who has ever taken 200 lines of Java code and reduced it to less than 50 lines of reactive Kotlin, anyone who has ever hit that Utopia of 100% unit test coverage in a class, or anyone who can actually read that 2-line Perl implementation of the RSA algorithm understands this simple truth. Software development is an art form. I am a Software Craftsman.

#wk171

If you feel it’s time to change I have a great job offer for you…
proceeds with offer with maximum wage that is half what you earn and by the way you need to know React, TypeScript, NextJS, Redux, NodeJS, ES6, Webpack, RESTful i GraphQL API
Nice to have is Python and Go

Girl you need to decide if it’s great offer or technology mishmash.
Hell no, glad you didn’t mentioned young and dynamic team cause I clearly see some dynamic technology stack there.

Company helps people find medical treatment clearly forgot about treatment on their stack.

Someone needs to tell them their tech leads are complete morons but since you’re not looking for head of technology it won’t be me lol.

I hate it when managers and team members don't utilise JIRA as the one source of truth.

When you move your card into the Review column, set the assignee to `unassigned` so that people know to pick it up. It's so much easier to understand the state of it !

"But then we don't know who's worked on it" - is NOT a valid reason to leave the original author as the assignee. It just leads to work not being reviewed.

I'm in a team of 3 in a small to medium sized company (over 50 engineers). We all work as full stack engineers.. but I think the definition of full stack here is getting super bloated. Let me give u an example. My team hold a few production apps, and we just launched a new one. The whole team (the 3 of us) are fully responsible on it from planning, design, database model, api, frontend (a react page spa), an extra client. Ok, so all this seems normal to a full stack dev.

Now, we also handle provisioning infra in aws using terraform, doing deployments, building a CI/CD pipeline using jenkins, monitoring, writing tests, building an analytics dashboard.

Recently our tech writer also left, so now we are also handling writing feature releases.

Few days ago, we also had a meeting where they sort of discussed that the maintenance of the engineering shared services, e.g. jenkins servers, (and about 2-3 other services) will now be split between teams in a shared board, previously this was handled only be team leads, but now they want to delegate it down.

And ofcourse not to mention supporting the app itself and updating bug tickets with findings.

I feel like my daily responsiblities are becoming the job responsibilities of at least 3 jobs.

Is this what full stack engineering looks like in your company? Do u handle everything from app design, building, cloud, ops, analytics etc..

Alright, let's talk about Scrum Masters. Honestly, I just can't wrap my head around why they're even a thing. It's like someone decided to invent a job title for a role that's already covered by other folks on the team.

I mean, think about it. Who's usually sorting out the team's issues, making sure everyone's on the same page, and keeping the project on track? That's right, it's the project manager or the lead dev. They're already in the trenches, dealing with the nitty-gritty, so why do we need this extra layer?

And don't even get me started on this "servant-leader" nonsense. It's like they're trying to be the team's buddy, but they've got no real power to make things happen. It's like being a king without a crown. Who's going to respect that?

Plus, having a Scrum Master often just leads to more red tape. Instead of getting stuff done, we're stuck in endless meetings, talking about process this and methodology that. It's like we're more focused on how we work instead of actually working.

The best teams I've seen don't need a Scrum Master to babysit them. They need a real leader, someone who's not afraid to make the tough calls and who can give them the tools they need to kick ass and take names.

So, in a nutshell, I think Scrum Masters are about as useful as a chocolate teapot. It's high time we ditched this outdated role and got back to doing what we do best: building awesome stuff.

I was moved from a team I loved where I felt my tech leads were competent, where my tech leads valued my skills and my manager was fabulous and excelled at making sure everyone had the resources they needed and was rewarded for good work, to a team where my tech leads are inconpetent and constantly treat all the junior devs with condescension. Additonally, although my new manager seems nice and has good intentions, she is focused too much on the results of work and not the morale of her team. Consequently, she consistently ignores the negative feedback that is given about the tech leads because "the tech lead gets the results"

A year since the Group Manager stepped into the position, 4 team leads have moved to other companies.
He is known to be politician/manipulative..

Guess what, Now there's a new Team Lead position and I was offered it.

It will be a step up for me, from senior engineer, and in other circumstances I would take the job in a heartbeat.

I guess it is not the time to step into leadership role.

What would you do?

Boss calls a team leads meeting which is just me and the other guy. Rest are product or project managers.

Turns out they concerns over how our last few sprints are always left unfinished as the work in it doesn't get passed QA.

Tried to tell him how can devs work on something that failed QA on the last day of the sprint.

We have one QA person who tests 20 something devs work. We are massively under resourced and yet they want us to do everything and always end up making promises to clients that we can't keep coz our sprint doesn't have capacity.

Yet they are hiring more product managers instead of getting some more QA help.

Sick & tired of this shit.

Working at a startup with a small (~4-6) person engineering team usually means those few people are the most in tune with the software. This then usually leads to an onslaught of people who should know better asking devs stupid questions about the software or relying on the devs to do their jobs for them.

Have you encountered these types of situations before? How were they resolved?

Hi everyone... first time posting....Ive been struggling at work and have failed to finish multiple tasks given to me... I fear because of this, my job will be in jeopardy. Although I ask for help, it seems I am still unable to finish the given task. This leads to me believing I'm not smart enough or cut to be a software developer and also lead me to think that it's better if I just quit as I'm just dead weight for my team. I'm not sure what to do.

Is it just i have bad luck or do all developers by the time they get to lead just stop caring?
my leads always seem to be the least team-focused members of the group.

I’ve now discovered that management actually decides for themselves what software engineering is. 🧐

It is getting increasingly common that in different architectural groups the decision has already been made… by management…without actually passing through our review… as a little more senior blokes and gals.

Not even a discussion? On the fit?

That leads me to the conclusion, since I consider the management (at least the two or three closest layers) are morons, good at talking but not really knowing anything about what we do (we kind of take stuff and make other stuff from it by using energy and other stuff in HUGE FUCKING FACILITIES AROUND THE PLANET), that even they did not make the decision. It was forced upon them. They did not decide either! Because they can’t! Because they are idiots all of them!

I have not investigated this issue but this is the logical conclusion. Or not.

Recently, for instance, decisions were made to route information flows by some tech. Some new tech. At some place in our eco-system. At a certain time. And, if we were to have reviewed this initiative in our process we would have said:

”Well, I hear you! But we are not going to do that right now because WE ARE IN THE MIDDLE OF THE FUCKING HUGE GLOBAL PROJECT THAT CHANGES PRETTY MUCH FUCKING EVERYTHING AND WE CAN NOT JUST IN THE MIDDLE OF THE FUCKING EXECUTION PROCESS OF THE PROJECT CHANGE THE FOUNDATIONS OF MESSAGE ROUTING BECAUSE WE LACK THE NUMBER OF HUMANS TO DO THE FUCKING JOB. So, we need to take a look at this and to get a better understanding when we can make this happen.”

What is the point of having this step in our organization if it is just pass-through? What is the point? Meetings? Just having meetings? Spending time mastering the organizational skill of administrating meetings? Feeling important? Using big words (holistic being my favourite)?

Below, juniors devs are being hired doing stupid stuff that does not need doing. For months and months.

I believe now that half of the dev staff does not need to be there and three quarters of the team, service, delivery (etc) managers are unnecessary. I mean, the good juniors are going to change jobs soon either way and we are stuck in this vicious cycle where we are not being allowed to be innovative in software engineering. Stability is of the essence here but the rate of our releases are just silly slow. I would say that we are far, far away from any track that leads us to where we want to be. Agile. Innovative. Close to business. Learning. Teaching. Faster. Stability despite response to implementing changing business needs.

And then there are the consultants…

*sigh*

is being a tech/dev person, a dead end job?

i have been thinking about this for sometime. as a dev, we can progress into senior dev, then tech lead, then staff engineer probably. but that is that. for a tech person :

1. their salary levels are defined. for eg, a junior may earn $10k pm , and the highest tech guy (say staff engineer) will earn $100k pm, but everyone's salary will be spread over this range only, in different slots.

2. some companies give stocks and bonuses , but most of the time that too is fixed to say 30% of the annual salary at max.

3. its a low risk job as a min of x number of tech folks are always required for their tech product to work properly. plus these folks are majorly with similar skills, so 2 react guys can be reduced to 1 but not because of incompetency .

4. even if people are incompetent, our domain is friendly and more like a community learning stuff. we share our knowledge in public domain and try to make things easy to learn for other folks inside and outside the office. this is probably a bad thing too

compare this to businesses , management and sales they have different:
1. thier career progression : saleman > sales team manager> branch manager > multiple branch manager(director) > multiple zones/state manager (president) > multiple countries/ company manager (cxo)

2. their salaries are comission based. they get a commission in the number of sales they get, later theybget comission in the sales of their team> their branch > their zone and finally in company's total revenue. this leads to very meagre number in salaries, but a very major and mostly consistent and handsome number in commission. that is why their salaries ranges from $2k pm to $2-$3millions per month.

3. in sales/management , their is a always a room for optimisation . if a guy is selling less products, than another guy, he could be fired and leads could be given to other/new person. managers can optimise the cost/expenses chain and help company generate wider profits. overall everyone is running for (a) to get an incentive and (b) to dodge their boss's axe.

4. this makes it a cut-throat and a network-first domain. people are arrogant and selfish, and have their own special tricks and tactics to ensure their value.

as a manager , you don't go around sharing the stories on how you got apple to partner with foxconn for every iphone manufacturing, you just enjoy the big fat bonus check and awe of inspiration that your junior interns make.

this sound a little bad , but on the contrary , this involves being a people person and a social animal. i remember one example from the office web series, where different sales people would have different strategies for getting a business: Michael would go wild, Stanley would connect with people of his race, and Phyllis would dress up like a client's wife.
in real life too, i have seen people using various social cues to get business. the guy from whom we bought our car, he was so friendly with my dad, i once thought that they are some long lost brothers.

this makes me wonder : are sales/mgmt people being better at being entrepreneur and human beings than we devs?

in terms of ethics, i don't think that people who are defining their life around comissions and cut throat races to be friendly or supportive beings. but at the same time, they would be connecting with people and their real problems, so they might become more helpful than their friends/relatives and other "good people" ?

Additionally, the skills of sales/mgmt translate directly to entrepreneurship, so every good salesman/manager is a billionaire in making. whereas we devs are just being peas in a pod , debating on next big npm package and trying to manage taxes on our already meagre , "consistent" income :/

mann i want some people skills like these guys

It's weird that I feel okay with team leads or managers who I know are lying about facts, just to motivate the team in some way. I mean I might lose respect to that person but I would somehow commend their people skills. A pat in the back goes a long way

Can someone explain to me the need of a "technical management"? I know my question is naive, but try to explain it like to kindergarten kid.

Case 1. When team is good, and has a good tech leader(s) then the software director/manager makes more harm with his silly ideas, pompous cliche "calls to arms" etc.

Case 2. On the other hand, when software team is shit, it means that the management is responsible for assembling such team. Then it further means that they can't distinguish impostors from really good talents, which leads to bad quality, missed deliveries, bugs, frustrations, etc.

I saw many times when good technical lead (aka architect, staff, principal) made a positive difference. But I NEVER EVER saw that things were bad and "manager/director" made a positive change. This concept is soooo flawed....

... any one explain please?

Hi all,
I'm in this company for about 15 months. It's one of the big name company. I'm a senior dev here. In my team we follow agile development. In starting I was just working on my part mostly. Then my manager raised concern to me for not taking ownership and helping others.
I started doing things what I could do. Like code review, API discussion, design discussion etc..
Now, the thing is I usually get upset when people go with 'lazy' solutions because I feel bad design leads to maintenance overhead, and it happened to us in past. We had to spend weekends to make things work. So, I started making code review, design review strict.
Some people didn't like it. But my manager was supportive, or at least I think so.

Some days back manager took me in a one-o-one discussion and told me one of the colleague kinda complained against me.

Now, my manager is not involving me into design discussions and API discussions. There are some new features are coming and I am not informed. I get to know things only in scrum-updates.

Am I about to get fired? I'm not gonna lie, I'm so scared. I can't put down papers as I'm already into 4th company in 7 years.

This thought is just killing me. What should I do? I'm so alone.

Continuation (no. 2): So because of my bad conscience I was very polite and friendly to the colleague I pestered about... but my boss was not. Instead he broke loose his second fight with Mr. git master. He's joking about that he now already had a fight with almost anybody (mostly team leads). He's leaving the company anyway, so he needn't care, but I start to love his love for conflicts. Some PM or upper boss already said something along the lines: "If something's wrong, I know you'll escalate." Of course you should not for every triviality, but nothing is worse than those lingering, dormant time bombs of projects that went so awry they're just waiting to explode... or silently be canceled.
Well, so they clashed again, and Mr git / scrum master fought for his concern that my boss, who's also product owner, must not enter the team. I looked at the git logs: Mr git master's only contribution - he's supposed to be a member of the team - since joining (like over a month) were 300 LOC, which was actually copy pasting our old copy right form, peppering it with some html tags to ensure it would not work without recompiling the 3rd party lib with a fucking webengine.

My boss now rather wants to remove "agile" as it's not fitting. Just let the three or four of us yank out the code so we actually have a chance to deliver in three months. He told the upper boss that we can take our tasks ourselves so independently we even need no team lead, but could report directly to him. It's still not clear what's gonna happen, but it's like they could let us loose, free radical elements who just do motherfucking programming. Feels awesome.

Question for leads...
Have you found that it's possible to have a balanced leadership style instead of ruling with an iron fist?

Let me explain what I mean.

There's always going to be room for improvement, there's going to be at least the occasional issue that happens, etc.
As a lead, your job is to not have issues happen and to have the team work effectively.

Now, for me, my goal was to have a balanced style in the sense that if there's a small issue or small room for improvement, but the team is already stressed, I take the heat for it if necessary and let them relax so they're not stressed and they can focus on the bigger things.
For medium improvements, I essentially put it to the vote so the team can have their say in whether they agree with the proposal on improvement.
And so on, idea being to have a balance between "Do what I tell you" and "do whatever you want".

However, I have found that doing so does essentially nothing to improve team morale and team cohesion. Any thing that needs doing and I force them into it, any thing I don't protect them from, any thing they don't agree with will still manifest as problems in the team, a single "you have to do this" will make them complain about the leadership style being "force to implement".

Being completely hands off and essentially not a lead, just basically a support dev more or less, is not what I'm really looking for, but also isn't good for a team that does genuinely have things that need to improve (stupid errors not being caught in dev OR review, system not being fully testable because of external dependencies that are not really necessary for tests, etc).

So the only option I see there is simply ruling with an iron fist and leaning into being that hated lead that just forcea you to do things and "doesn't care about you".
I've already stepped down from this lead position because I don't want to be that guy, but if I'm looking for another position I'm curious if this is just universal or hae you guys found that it IS possible to have a "good team" where you can be adults and discuss things as a team and improve as a team?

Our company just turned most of the team leads into managers to unflatten the organization. Most of the team leads really shouldn't be managers, nor do many of them have any desire to.

Normally a company that wants to do this will create a few manager positions, and let everyone in the company apply for them first, before opening it up externally.

The way they've rolled this out seems like it can only be disastrous.

So today I needed produce some files with an unknown file name, not specified by business. I said in the standup that I still don't know what it is supposed to be. BA says they will find out. Speak to them all day discussing it. The architect says its in the documentation. BA and I don't find it. Turns out it isn't. I ask a sister team what they did in a similar situation, they said they named it something arbitrary and moved on. I was like sweet, GG story. Later I'm discussing work with my tech lead. Email pops up look at that and read. Look back at tech leads screen. What do I see, file names. At this point I'm frustrated because all I see is file names that look similar. My senior then speaks and says 'Yeah we've seen them for X days now' I'm like really? He says yeah and I hope we don't get anymore people like you. At this point my colleague dev bursts out laughing and I feel humiliated. Only to realise they are the names of other files. Try to explain myself but my senior is already looking at his PC doing sweet fa.

I'm now raging a bit inside and want to leave but can't because I'm tied into a horrible contract.

So Today I realised I'm might be being bullied by my senior dev.

After a week of designing an API to our system for another team followed by redesigning it because they 'know what they need when they see it' I think I understand the pains all of you guys who work directly with customers go through what leads to exactly one question : How did you manage to never kill anyone?

Making music definitely made me a better programmer. In fact playing lots of instruments showed me the different roles that exist on a team. Lead guitarists are kinda like programmers, constantly looking for the next challenging song to make. Singers and rhythm guitarists are like the team leads and PMs who want a nice bow on the product. Drummers are like designers really, they kinda show up and make something bad ass and disappear. Bass players are like solid backend or ops folks silently making stuff stable and grounded.

Some background:

About 2 months ago, my company wanted to build a micro service that will be used to integrate 3 of our products with external ticketing systems.

So, I was asked to take on this task. Design the service, ensure extendability and universality between our products (all have very different use cases, data models and their own sets of services).

Two weeks of meetings with multiple stakeholders and tech leads. Got the okay by 4-6 people. Built the thing with one other guy in a manner of a week. Stress tested it against one ticketing service that is used in a product my team is developing.

Everyone is happy.

Fast forward to last Thursday night.

“Email from human X”: hey, I extended the shared micro service for ticketing to add support for one of clients ghetto ticketing systems. Review my PR please. P.S. release date is Monday and I am on a personal day on Friday.

I’m thinking. Cool I know this guy. He helped me design this API. He must’ve done good. . . *looks at code* . . . work..... it’s due... Monday? Huh? Personal day? Huh?

So not to shit on the day. He did add much needed support for bear tokens and generalized some of the environment variables. Cleaned up some code. But.... big no no no...

The original code was written with a factory pattern in mind. The solution is supposed to handle communication to multiple 3rd parties, but using the same interfaces.

What did this guy do wrong? Well other than the fact that he basically put me in a spot where if I reject his code, it will look like I’m blocking progress on his code...

His “implementation” is literally copy-paste the entire class. Add 3 be urls to his specific implementation of the API.

Now we have

POST /ticket
PUT /ticket
POST /ticket-scripted
PUT /ticket-scripted
POST /callback

The latter 3 are his additions... only the last one should have been added in reality... why not just add a type to the payload of the post/put? Is he expecting us to write new endpoints for every damn integration? At this rate we might as well not have this component...

But seriously this cheeses me... especially since Monday is my day off! So not only do I have to reject this code. I also have to have a call now with him on my fucking day off!!!!

Arghhhhhh

!rant

Agile devs— do you attend sprint planning?

I want to, but my boss told me not to go (waste of my time, he says). Only leads attend them, then they come back with tickets for the rest of the team. But a few other devs I’ve spoken to found that absurd, since attending lets you choose your tickets to a certain extent.

Do you attend yours? Is it crazy not to? Am I missing out? (I ask bc ours is happening right now— and it’s so empty in here!)

Tried to explain to the department lead that having devs spend more time documenting what we spend time on, asking for permissions to do anything doesn't make the project go faster.

Leads might feel good about having better overview for themselves, but in reality you just slowed down, demotivated and annoy the entire team of people doing the actual work. Noone wants to or will do overtime because we have to ask for permission first. And you took away one good dev to spend his entire days in meetings instead of actually doing any real work on the project.

#releasethedevs

Do you have meetings that your team have to bring technical subjects to talk about? We have it here, but it doesn't seem people like it, and it's difficult to find someone willing to talk. I wondered why the leads or managers insist on having these kinds of meetings.

Does rapid application development methodology leads to more technical debt compare to other ones? With a factor like deadlines, a small number of team etc? 🤔