Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuckBuy Now
Search - "team leads"
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.23
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.15
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.
Wish me luck. 😎1
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.5
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.7
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 me5
➡️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²
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?
Article by Eduards Sizovs
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.8
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.2
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?10
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?8
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.18
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...6
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.
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.3
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.4
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 :(1
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...
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....4
So how do team leads get away with saying "Hol' up, I ain't technical" when you try to explain something?4
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!3
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.1
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.11
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.
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 :(2
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.
- 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!
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 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 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 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.4
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.
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"
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?2
Ahh, this particularly memorable occasion, it’s not much of a “fight” per se, but remembering the events I really want to beat the shit out of those asshats,
Backstory, I was working in a project, big one, my previous one, we had all this “squads” to say, agile teams consisted of several devs, I was happily working in my squad namely squad “A”, until one day by the end of a sprint my PO asked me to help another squad, call it squad “B”,
Curious for the reason as I may be, I ignored it at first, after all having the higher up owing me one is always welcome, A and B are having similar amount of dev team, with A having 1 more Front End developer,
Skipping the boring detail, continue on to my first sprint, I saw problems within the team, the other 4 FE consisted of 2 foreigners (call them “the good guys”) and 2 of our own (same vendor as me, let’s call them “the pricks”),
The ones leading discussions most of the time are the pricks, the good guys usually keep their mouth shut, calm and composed, and when shit happens, the good guys usually fix the problem without any fuss, on the contrary, the pricks threw fit all over the place trying to find somone to blame first,
Skip all the excruciating 2 weeks of trying to guide them in the right way, and talking with their PO, my PO, tech leads, etc, I came across a development of a certain feature, PR already made and waiting for review from a TL, then being the impatient ass B’s PO is, he pushed me to ask for a review from another TL, and the only one available is “the meticulous and perfectionist” TL, which is definitely not my choice in any given order,
Simple math, I assigned my review to TL X, wait a day, it’ll definitely be merged within a day, give it to TL Y, he reviews it immediately, and he’ll find all these shit squad B’s been writing, and then I’ll be spending 3 days trying to clean it up, but no matter, the PO insist on having it reviewed first,
Lo and behold, it happened, I had to refactor all the shit the pricks have been writing, again, I took the high road, until I stumbled upon a piece of code that just doesn’t makes any sense, no matter how exhaustively I put the effort to trace it out, an hour passed by and I decided to ask the pricks, let’s call them #1 and #2, #1 being the senior prick, and #2 being the regular prick but bigger pain in the ass, it went on something like this,
Me: uhh, sorry to bother you guys, but what’s this piece is used for?
#2: huh? Dunno, last guy to touch it was #1
Me: eeh, but the line history says it’s you,
#2: strange, I don’t remember, for testing probably
Me: well TL said to remove this one if it’s unused, I want to know if it’ll affect any functionality
#2: well, go figure
Me: yep that’s why I’m asking
#2: well, if you don’t need it just remove it
Me: again that’s what I’m trying to figure out, will it affect any functionality, since time is pressing I don’t have room for experimenting so I’m trying to find some solution by asking the creator if he might have any insight on this matter
#2: well don’t ask me, try asking #1
Me: dear sir #1 have you the faintest idea of what this piece of scripture might mean?
#1: huh? No idea, #2 wrote it
#2:... I don’t remember, I thought it was you,
#1: see the git blame, it’s #2
Me: guys, since we’re not getting anywhere, I’ll just go against my guts and remove it, so that everyone can live happily ever after,
#2: wait, who’s asking?
Me: the reviewing TL,
#2: yes, who?
Me: mr Y
#2: let’s meet with him
Me: what for?
#2: you said he wants to delete the code, let’s have a chat with him
Me: *not this shit again
#2: what are we waiting for, let’s go,
Me: naah, no need I’ll just delete it as you said it first, sorry, my bad
#2: what’d you say?
Me: I already deleted it, nevermind
#2: why did you do that? If the TL doesn’t like it let’s have a chat
Me: and what would be the point of that? I deleted it already, case closed, I’ll take the responsibility for fixing anything that may come up later, I don’t have time for your childish shit,
#2: *glares at me
Me: *glares back
#1: now, now, let’s all take a step back here, blah blah blah
#2: blah blah blah
And they both starts arguing with each other after #1 tries to act all diplomatic, I left them to their own discussion, and proceed with the PR,
Thankfully removing the piece of code doesn’t affect anything, it seems like #1 or #2 forgot to delete it when fixing the unit test some commits ago1
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.
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.6
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.7
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.2
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.
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 way2
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?1
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.1
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.
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.
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!)5
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? 🤔