1. I join a company.

2. I get deeply involved in "how to run the company", and get nice compliments from both coworkers & management about my skills in conveying startup/scaleup advice & necessities to upper management.

3. With my ego inflated through all the sweet talk, I think "ah, what the hell, let's do this again", and I accept a Lead/CTO promotion. I have to join board meetings, write reports on quarterly plans and progress.

4. I get unhappy/stressed/burned-out because I really just want to be a developer, not a manager/executive.

5. Upper management understands, I give up my lead position, lock myself back into my coding cave.

6. I get annoyed because the requirements I receive become more and more disconnected from reality, half of the teams seem to have decided to stop using agile/scrum, the testing pipeline breaks all the time, I get an updated labor contract from HR by mail which smells like charred flesh, etc

7. The annoyances become too much to do ANY work. I yell at the other devs outside of the entrance of my cave. There is no answer, only a few painful moans and sighs.

8. I emerge from my cave. The city has turned into a desolate wasteland. The office is a burning ruin, the air sharp and heavy with black soot. Disemboweled corpses of developers litter the poisoned soil.

Product Managers dressed in stained ripped suits scream at each other while they try to reinforce concrete barricades with scotch tape and post-its. *THUMP* Something enormous is trying to break through. "Thank God, bittersweet, you're still alive! The stakeholders! They have mutated! We couldn't meet the promised deadlines! We've lost the whole mobile app department, and that kid there is the last of the backenders and he's only an intern! You're here to save us, right? RIGHT?".

In the corner, between the overflowing coffee machine and a withered cactus, a young boy has collapsed onto the floor. His face is covered in moldy coffee grounds, clasping on to his closed macbook for dear life, wide-open eyes staring into the void, mumbling: "didn't backup the database, and It's all gone" over and over.

A severely dented black Tesla with a dragging loose bumper breaks through the dried up vertical herb garden and the smoothiebar, and comes to a halt against the beanbags in a big cloud of styrofoam balls.

The CEO limps out, leaking blood all over the upholstery. He yells to the COO: "The datacenter is completely flooded with sewage! I saved the backup tapes though", holding a large nest of tangled black magnetic tape mixed with clumps of mud above his head.

9. I collect my outstanding salary and sell any rewarded options/shares for a low dumping price, take a 5 month holiday, and ask a recruiter about opportunities in a different city.

Fresh out of college?
Entry-level?
Apply Here!

Junior Web Intern: 16k A Year!
Basic Requirements: HTML, CSS, JavaScript, Node, Angular, JQuery, Bootstrap, Backbone, Handlebars, D3, p3, CMS (WordPress, Wixx), PHP, Java (Android), C++(iOS), openframeworks, openGLSL, Cinder, failed at least two startups, 8086 assembly language.

Recommended requirements:
Git version control
Agile development

Must be able to display example of each requirement.

Privacy & security violations piss me off. Not to the point that I'll write on devRant about it, but to the point that coworkers get afraid from the bloodthirsty look in my eyes.

I know all startups proclaim this, but the one I work at is kind of industry-disrupting. Think Uber vs taxi drivers... so we have real, malicious enemies.

Yet there's still this mindset of "it won't happen to us" when it comes to data leaks or corporate spying.

Me: "I noticed we are tracking our end users without their consent, and store not just the color of their balls, but also their favorite soup flavor and how often they've cheated on their partner, as plain text in the system for every employee to read"

Various C-randomletter-Os: "Oh wow indubitably most serious indeed! Let's put 2 scrumbag masters on the issue, we will tackle this in a most agile manner! We shall use AI blockchains in the elastic cloud to encrypt those ball-colors!"

NO WHAT I MEANT WAS WHY THE FUCK DO WE EVEN STORE THAT INFORMATION. IT DOES IN NO WAY RELATE TO OUR BUSINESS!

"No reason, just future requirements for our data scientists"

I'M GRABBING A HARDDRIVE SHREDDER, THE DB SERVER GOES FIRST AND YOUR PENIS RIGHT AFTER THAT!

(if it's unclear, ball color was an optimistic euphemism for what boiled down to an analytics value which might as well have been "nigger: yes/no")

Story time. My first story ever on devRant.

To my ex-company that I bear for a long time... I joined my ex-company 3 years ago. My ex-company assigned me and one girl teammate to start working on a brand new big web project (big one - two members - really?)

My teammate quitted later, I have to work alone after then. I asked if someone can join this project, but manager said other people are busy. Yea, they are fucking busy reading MANGA shit everyday... Oops, I saw it because whenever I about to leave my damn chair, they begin chanting some hotkey magic and begin doing "poker face" like "I'm doing some serious shit right here".. FUCK MY CO-WORKERS!

My manager didn't know shit about software development, and keep barking about Agile, Waterfall and AI shit... He didn't even fucking know what this project should look like, he keep searching the internet for similar functions and gave me screenshots, or sometimes they even hold a meeting of a bunch of random non-related guys who even not working on the project, to discuss about requirements, which last for endless hours... FUCK MY MANAGER!

I was the one in charge for everything. I design the architecture, database, then I fucking implement my own designed architect myself, and I fucking test functions that I fucking implemented myself based on my fucking design. I was so tried, I don't know what the fuck I am working on. Requirement changes everyday. My beautiful architecture began to falling off. I was so tired and began use hack fixes here and there many places in the project. I knew it's bad, but I just don't have time to carefully reconsider it. My test case began becoming useless as requirements changed. My manager's boss push him to finish this project. He began to test, he start complaining about bug here and there, blaming me about why functions are broken, and why it not work as he expected (which he didn't even tell my how he expected). ... I'm not junior developer, but this one-man project is so overwhelmed for me... FUCK MY JOB!

At this time, I have already work this project for almost 2.5 years. I felt very upset. I also feel disappointed about myself, although I know that is not all my entire faults. The feeling that you was given a job, but you can not get it done, I feel like a fucking LOSER. I really wanted to quit and run away from this shithole. But on the other hand I also want to finish this project before I quit. My mind mixed. I'm a hard-worker. I keep pushing myself, but the workplace is so toxic, I can feel it eating up my motivation everyday. I start questioning myself: "Is the job I am doing important?", "If this is really important project, didn't they should assign more members?", I feel so lonely at work... MY MIND IS FUCKED UP!

Finally, after a couple months of stress. I made up my mind that no way this project is gonna end within my lifespan. I decide to quit. Although my contract pointed that I only need to tell one month in advance. I gave my manager 3 months to find new members for project. I did handle over what I know, documents, and my fucked up ultra complexity source code with many small sub-systems which I did all by myself.

Well, I am with a new employer right now. They are good company. At least, my new manager do know how to manage things. My co-workers are energy and hard-working. I am put to fight on the frontline as usual (because of my "Senior position"). But I can feel my team, they got my back. My loneliness is now gone. Job is still hard, but I know for sure that I'm doing things on purpose, I am doing something useful. And to me that is the greatest rewards and keep me motivative! From now, will be the beginning for first page of my new story...

Thanks for reading ...

We have no more time for all this Agile stuff!

Half of our developers might have been injured when we built the Great Wall of China, but no worries, we've listened to your complaints about feeling overworked!

You can take 3 extra days off this year. Meanwhile, we're starting the next project.

We're building some pyramids.

What? You want Scrum and sprints? Sure, do sprints, whatever helps us build those pyramids!

Requirements? Refinements? What requirements are there to refine?

We require a giant pyramid.

For v1, you can build the foundation out of wet mud. It must be 500 meters. Wide, or high, we're not sure yet, we'll get back to you on that. It must have less than 4 sides, but certainly more than 3.

The Frontend team has already built a part of the entrance using 60 semi trucks filled with papier-mâché, pipe cleaners and glitter.

Now go build already!

TL;DR :

"when i die i want my group project members to lower me into my grave so they can let me down one last time"

STORY TIME

Last year in College, I had two simultaneous projects. Both were semester long projects. One was for a database class an another was for a software engineering class.

As you can guess, the focus of the projects was very different. Databases we made some desktop networked chat application with a user login system and what not in Java. SE we made an app store with an approval system and admin panels and ratings and reviews and all that jazz in Meteor.js.

The DB project we had 4 total people and one of them was someone we'll call Frank. Frank was also in my SE project group. Frank disappeared for several weeks. Not in class, didn't contact us, and at one point the professors didn't know much either. As soon as we noticed it would be an issue, we talked to the professors. Just keeping them in the loop will save you a lot of trouble down the road. I'm assuming there was some medical or family emergency because the professors were very understanding with him once he started coming back to class and they had a chance to talk.

Lesson 1: If you have that guy that doesn't show up or communicate, don't be a jerk to them and communicate with your professor. Also, don't stop trying to contact the rogue partner. Maybe they'll come around sometime.

It sucked to lose 25% of our team for a project, but Frank appreciated that we didn't totally ignore him and throw him under the bus to the point that the last day of class he came up to me and said, "hey, open your book bag and bring it next to mine." He then threw a LARGE bottle of booze in there as a thank you.

Lesson 2: Treat humans as humans. Things go wrong and understanding that will get you a lot farther with people than trying to make them feel terrible about something that may have been out of their control.

Our DB project went really well. We got an A, we demoed, it worked, it was cool. The biggest problem is I was the only person that had taken a networking class so I ended up doing a large portion of the work. I wish I had taken other people's skills into account when we were deciding on a project. Especially because the only requirement was that it needed to have a minimum of 5 tables and we had to use some SQL language (aka, we couldn't use no-SQL).

The SE project had Frank and a music major who wanted to minor in CS (and then 3 other regular CS students aside from me). This assignment was make an app store using any technology you want. But, you had to use agile sprints. So we had weekly meetings with the "customer" (the TA), who would change requirements on us to keep us on our toes and tell us what they wanted done as a priority for the next meeting. Seriously, just like real life. It was so much fun trying to stay ahead of that.

So we met up and tried to decided what to use. One kid said Java because we all had it for school. The big issue is trying to make a Java web app is a pain in the ass. Seriously, there are so many better things to use. Other teams decided to use Django because they all wanted to learn Python. I suggested why not use something with a nice package system to minimize duplicating work that had already been done and tested by someone. Kid 1 didn't like that because he said in the real world you have to make your own software and not use packages. Little did he know that I had worked in SE for a few years already and knew damn well that every good project has code from somewhere else that has already solved a problem you're facing. We went with Java the first week. It failed miserably. Nobody could get the server set up on their computers. Using VCS with it required you to keep the repo outside of the where you wrote code and copy and paste changes in there. It was just a huge flop so everyone else voted to change.

Lesson 3: Be flexible. Be open to learning new things. Don't be afraid to try something new. It'll make you a better developer in the long run.

So we ended up using Meteor. Why? We all figured we could pick up javascript super easy.Two of us already knew it. And the real time thing would make for some cool effects when an app got a approved or a comment was made. We got to work and the one kid was still pissed. I just checked the repo and the only thing he committed was fixing the spelling of on word in the readme.

We sat down one day and worked for 4 straight hours. We finished the whole project in that time. While other teams were figuring out how to layout their homepage, we had a working user system and admin page and everything. Our TA was trying to throw us for loops by asking for crazy things and we still came through. We had tests that ran along side the application as you used it. It was friggin cool.

Lesson 4: If possible, pick the right tool for the job. Not the tool you know. Everything in CS has a purpose. If you use it for its purpose, you will save days off of a project.

I'm coming off a lengthy staff augmentation assignment awful enough that I feel like I need to be rehabilitated to convince myself that I even want to be a software developer.

They needed someone who does .NET. It turns out what they meant was someone to copy and paste massive amounts of code that their EA calls a "framework." Just copy and paste this entire repo, make a whole ton of tweaks that for whatever reason never make their way back into the "template," and then make a few edits for some specific functionality. And then repeat. And repeat. Over a dozen times.

The code is unbelievable. Everything is stacked into giant classes that inherit from each other. There's no dependency inversion. The classes have default constructors with a comment "for unit testing" and then the "real" code uses a different one.

It's full of projects, classes, and methods with weird names that don't do anything. The class and method names sound like they mean something but don't. So after a dozen times I tried to refactor, and the EA threw a hissy fit. Deleting dead code, reducing three levels of inheritance to a simple class, and renaming stuff to indicate what it does are all violations of "standards." I had to go back to the template and start over.

This guy actually recorded a video of himself giving developers instructions on how to copy and paste his awful code.

Then he randomly invents new "standards." A class that reads messages from a queue and processes them shouldn't process them anymore. It should read them and put them in another queue, and then we add more complication by reading from that queue. The reason? We might want to use the original queue for something else one day. I'm pretty sure rewriting working code to meet requirements no one has is as close as you can get to the opposite of Agile.

I fixed some major bugs during my refactor, and missed one the second time after I started over. So stuff actually broke in production because I took points off the board and "fixed" what worked to add back in dead code, variables that aren't used, etc.

In the process, I asked the EA how he wanted me to do this stuff, because I know that he makes up "standards" on the fly and whatever I do may or may not be what he was imagining. We had a tight deadline and I didn't really have time to guess, read his mind, get it wrong, and start over. So we scheduled an hour for him to show me what he wanted.

He said it would take fifteen minutes. He used the first fifteen insisting that he would not explain what he wanted, and besides he didn't remember how all of the code he wrote worked anyway so I would just have to spend more time studying his masterpiece and stepping through it in the debugger.

Being accountable to my team, I insisted that we needed to spend the scheduled hour on him actually explaining what he wanted. He started yelling and hung up. I had to explain to management that I could figure out how to make his "framework" work, but it would take longer and there was no guarantee that when it was done it would magically converge on whatever he was imagining. We totally blew that deadline.

When the .NET work was done, I got sucked into another part of the same project where they were writing massive 500 line SQL stored procedures that no one could understand. They would write a dozen before sending any to QA, then find out that there was a scenario or two not accounted for, and rewrite them all. And repeat. And repeat. Eventually it consisted of, one again, copying and pasting existing procedures into new ones.

At one point one dev asked me to help him test his procedure. I said sure, tell me the scenarios for which I needed to test. He didn't know. My question was the equivalent of asking, "Tell me what you think your code does," and he couldn't answer it. If the guy who wrote it doesn't know what it does right after he wrote it and you certainly can't tell by reading it, and there's dozens of these procedures, all the same but slightly different, how is anyone ever going to read them in a month or a year? What happens when someone needs to change them? What happens when someone finds another defect, and there are going to be a ton of them?

It's a nightmare. Why interview me with all sorts of questions about my dev skills if the plan is to have me copy and paste stuff and carefully avoid applying anything that I know?

The people are all nice except for their evil XEB (Xenophobe Expert Beginner) EA who has no business writing a line of code, ever, and certainly shouldn't be reviewing it.

I've tried to keep my sanity by answering stackoverflow questions once in a while and sometimes turning evil things I was forced to do into constructive blog posts to which I cannot link to preserve my anonymity. I feel like I've taken a six-month detour from software development to shovel crap. Never again. Lesson learned. Next time they're not interviewing me. I'm interviewing them. I'm a professional.

"A well defined problem is a problem half solved."
~ Charles Kettering.

Feel like crying on hearing this when the product feature requirements change in so aGiLe way.

While this wasn't technically a real client, it's still one of the most insane requests I've ever had.

I chose to specialize in software engineering for the last year and a half of my degree, which meant a lot of subjects were based around teamwork, proper engineering practises, accessibility, agile methods, basically a lot of stuff to get us ready to work in a proper corporate dev environment. One of our subjects was all about project management, and the semester-long coursework project (that was in lieu of a final exam) was to develop a real project for a real client. And, very very smartly, the professors set up a meeting with the clients so that the clients could tell us what they wanted with sixty-odd students providing enough questions. They basically wanted a management service for their day-center along with an app for the people there. One of the optional requirements was a text chat. Personally not something I'm super interested in doing but whatever, it's a group project, I'll do my part.

The actual development of the project was an absolute nightmare, but that's a story for another day. All I'll say is that seven juniors with zero experience in the framework we chose does not make a balanced dev team.

Anyway, like three months into the four-month project we've got a somewhat functional program, we just need to get the server side part running and are working our asses off (some more than others) when the client comes in and says that 'hey, nice app, nobody else has added the chat yet, but could you do voice recognition okay thanks?'.

Fucking.
Voice.
Recognition.

This was a fucking basic-ass management app with the most complicated task being 'make it look pretty' and 'hook up a DB to an API' and they want us to add voice recognition after sitting on their ass for three months??? The entire team collectively flipped its shit the second they were out of earshot. The client would not take no for an answer, the professor simply told us that they asked for it and it was up to us whether we delivered or not. Someone working on the frontend had the genius idea of 'just get them to use google voice recognition' so we added the how-to in the manual and ticked the requirement box.

What amazes me about all that is how the client probably had no idea that their new last-minute request was even a problem for us, let alone it being in a completely different ballpark in terms of implementing from scratch.

devRant is awesome, but Disney also manages to light-up my day.
This is how Wall-E became a beloved member of our team, and helped me put a smile on my face throughout a very frustrating project.

It all started in a company, not so far far away from here, where management decided to open up development to a wider audience in the organization. Instead of continuing the good-old ping-pong between Business and IT...

'not meeting my expectations' - 'not stated in project requirements'
'stuff's not working - 'business is constantly misusing'
'why are they so difficult' - 'why don't they know what they really want'
'Ping, pong, plok... (business loses point) ping, pong'

... the company aimed to increase collaboration between the 2 worlds, and make development more agile.

The close collaboration on development projects is a journey of falling and getting back up again. Which can be energy draining, but to be honest there is also a lot of positive exposure to our team now.
The relevant part for this story is that de incentive of business teams throughout these projects was mainly to deliver 'something' that 'worked'. Where our team was also very keen on delivering functionality that is stable, scalable, properly documented etc. etc.
We managed to get the fundamentals in place, but because the whole idea was to be more agile or less strict throughout the process, we could not safeguard all best-practices were adhered to during each phase of a project. The ratio Business/IT was simply out of balance to control everything, and the whole idea was to go for a shorter development lifecycle.
One thing for sure, we went a lot faster from design through development to deployment, high-fives followed and everybody was happy (for some time).
Well almost everybody, because we knew our responsibility would not end after the collection of credits at deployment, but that an ongoing cycle of maintenance would follow. As expected, after the celebrations also complaints, new requirements and support requests on bug fixes were incoming.
Not too enthusiastic about constantly patching these projects, I proposed to halt new development and to initiate a proper cleaning of all these projects. With the image in mind of a small enthusiastic fellow, dedicated to clean a garbage-strewn wasteland for humanity, I deemed "Wall-E" a very suited project name. With Wall-E on board, focus for the next period was on completely restructuring these projects to make sure all could be properly maintained for the future.
I knew I was in for some support, so I fetched some cool wall papers to kick-start each day with a fresh set of Wall-E's on my monitors. Subsequently I created a Project Wall-E status report, included Wall-E in team-meetings and before I knew it Wall-E was the most frequently mentioned member of the team. I could not stop to chuckle when mails started to fly on whether "Wall-E completed project A" or if we could discuss "Wall-E's status next report-out". I am really happy we put in the effort with the whole team to properly deploy all functionality. Not only the project became a success, also the idea of associating frustrating activities with a beloved digital buddy landed well in our company. A colleagues already kickstarted 'project Doraemon', which is triggering a lot of fun content. Hope it may give you some inspiration, or at least motivate you to watch Wall-E!

PS: I have been enjoying the posts, valuable learnings and fun experiences for some time now. Decided to also share a bit from my side, here goes my first rant!

There's nothing like finishing the build for a 4 month project, send it for testing and then there's change requests that fundamentally change what the fuck you built.

Some days a good bottle of bourbon or 5 are needed. 😤🥃

This is PART 1/2 of a series of rants over the course of a software engineering class years ago.

We were four team members, two had never failed a class, I’ll refer to them as MT and FT, male and female top students, respectively, and an older student with some real world experience who I’ll refer to as SR.

Rant 1: As I was familiar with the agile methodologies I became the Scrum Master and was set with the task of explaining it to the team members, SR showed up late and nobody seemed interested in learning new methodology. At this point I knew we'd have trouble as a team.

Rant 2: FT made up her project proposal without informing anybody, which required a real client/product owner. We only figured it out after her proposal was accepted as the project, so we ended up working with fake requirements.

Rant 3: This one is partly my fault. I researched first and then worked, which meant I was the last to turn up my work. In one activity MT pressures me and I agree to a deadline so everyone can send their work to the teacher in a timely manner. Since I was the last to finish, I was also asked to give the doc some formatting, which I did in a hurry so it wasn't the best.
The next day MT and FT start complaining about me, saying I took too long and that they expect me to do better next time or else. At the same time they were stressed and in a hurry because we had to explain the project outline in front of the class and they didn't study.
Turns out copying and pasting all your work in less than an hour means you don’t learn anything. FT actually asked me for help days before and I sent her a website in English, which she wasn't very good at, so she just ran it through Google Translate and called it a day.
Later FT called me rude for interrupting MT in the presentation, which I did because he started making up stuff about the project.

Rant 4: SR expressed his dislike for school through profanity in variable names and commit messages. This caused MT and FT to dislike him. I thought it was immature but if anything it should’ve been reported to the teacher and move on.

Rant 5: I was stuck trying to get the REST API working for the project Admittedly this was my fault, too, because I was pushing for the usage of things nobody was familiar with for the sake of learning. This coupled with SR’s profanity led to drama and the progress was dropped, starting over from scratch.

At this point I stepped down from the Scrum Master role as nobody seemed to listen anymore.

Waterfall Project Stages:
Requirements, Analysis, Design, Coding, Testing, Operations

When you promote project managers to program managers and tell them to switch to Agile, you get the Agilefall project stages:
Best guess, Timeline, User stories, Execution, Blame the devs when the project plan trends late.

I want to beat them with a copy of the PMBOK wrapped in lead.

"I don't believe in software development methodologies, agile is absurd. Just tell me the exact HOURS you will spend doing research, gathering requirements, etc. I want to know the justification on why you will spend those many hours doing those task"

Two months of meaningless meetings and calls to assess "requirements" and three months worth of actual development work crammed into 3 weeks. Fuck this corporate bs. Agile my ass.

What are your thoughts on working for a company that give their devs jira tickets that don't have any descriptions? I work for a big organisation (It's actually in the top 3 biggest companies in the country I live in) and I work in a team that has quite possibly the worst agile practice I've ever seen. We get tickets without any descriptions at all. The worst bit is then we get pressure from project management for not delivering things on time. Do they actually realise how difficult it is to deliver something without any business requirements? I have to have a million meetings before I even know wtf the ticket is about. It's incredibly annoying.

I'm a tech lead for a new agile project for a manager who knows nothing about agile. Having to work on a chart that shows exactly how many sprints each milestone will be and when it will complete for like, 17 sprints from now when requirements aren't even set. Wtf?

Last day of agile project i get asked for confirmation that the alpha system can handle 100000 records. We have had no load testing requests only feature pushes every sprint.

I see the back-end guys have used EF in a search function that eager joins a bunch of tables. Then the results get sorted and filtered in application code. It works fine for a few hundred records but the customer will do about 100k new records a year.

Yeah this won’t meet requirements. I wish they asked for some load testing before the last day. They aren’t going to like that one person can do a search every 15 seconds by the end of the year when I tell them. FML

That moment when agile means "I will sneak in new feature requirements in with your bug tickets even though our sprint is supposed to be only stabilization". Thanks PM Lord.

I think the sleep deprived me is finally cracking under the weight of incompetent assholes.

We just launched a major project in some weird cocktail of Agile slapped with MVP and release to the wild in a waterfall, but it was premature, premature in the sense QA hasn't even finished their side of things, but because some fuck with with "manager" in their title decided they have burnt through the budget with incompetence and scrapped an entire element of the project and outsourced just so they could make a shittier version that doesn't even fucking work.

How hard do you want to fail before you will start listening to the people that now have to work around the fucking clock to clean up this horse shit of a mess.

I'm literally arguing over field mapping with multiple 3rd parties, when the fucking requirements state WTF this is suppose to look like. All because they didn't validate or test their own shit.

Why is EVERY FUCKING cock head in this industry a waste of space and cash! Is it really to much to ask for 1 fucking project to fucking go live that actually fucking works where I don't need to work 2 weeks straight (including weekends) after going live just to be sure that what shit does hit the fan isn't going to create a SEV 1 issue...

Sorry, I'm pissed at the incompetence of others I need to deal with on a daily basis. It's not like this field is insanely hard. A little attention to detail and self validation, verification goes a long way. But clearly that's a rarity.

Once this shit is stable and actually works, I'll be pulling out the mop to clean up half this shit just so it actually works.

Oof, I'm getting to old for this bullshit.

So the company decided to go agile. I am now a scrum master. And we have the local product owners and all. They made us do daily stand-ups.

I don't know what is a scrum master. Nobody knows what the hell is a stand-up. It seems to be an akward 30 minutes every day, when local product owner asks questions and demands status reports.

I did some googling and it seems that the scrum master is supposed to just support the team and solve problems. In our version the scrum master finds out the system architecture and requirements, fills the backlog, does the system design and reports to the project manager(s). Also reports to the clients about the general project status in an executive meetings. I also do the sprint planning, in which we fit the vague features that we are told into time tables with ready told dates.

Oh yeah, the team is just 2 guys. One of them is me. And the other guy relies completely on me to daily tell what to do, review the work and also answer all the project and company level questions that pop into his mind. He gets angry if he doesn't receive ready-thought solutions to all problems, since "you're the boss and it's your job to tell us what to do".

This is going to be a great year.

Job BS that made me consider quitting?

Huh. so timely.

With my previous employer, it was the whole "we're doing Agile and sprints and all the things" with "finish the project in six weeks plus here are some more requirements" garbage. Plus my tech lead always let the business roll over her and add unplanned requirements during a sprint without adjusting the deadlines set by the project managers. In summary: a fuck-all combination of Waterfall deadlines, Kanban tickets and Scrum timeboxes.

At my current employer, it's our business partners who're a bunch of douchebags that don't plan for anything except making sure their bonuses stay intact. Recently they terminated support for a third-party product that literally drives 99% of their web application then says to us "Hey, we need to build our own replacement for the vendor product using an entirely new stack. You have 3 months or our clients will get pissed." Oh, and these business partners keep raising new issues without any documentary basis except "this doesn't feel right" when they test our in-progress work. So helpful <sarcasm />

On the bright side, I'm getting paid whether or not this project fails, so... meh.

Agile is a fancy word for we, the top Dawgs can change the requirements at any time and you dev peasants will have to deal with it.

I know I’ll get mixed views for this one...

So I’ll state my claim. I agree with the philosophy of uncle bob, I also feel like he is the high level language - older version of myself personality wise.. (when I learned about uncle bob I was like this guy is just like me but not low level haha).

Anyway.. I don’t agree with everything because I think he thinks or atleast I get the vibe he thinks everything can be solved by OOP, and high level languages. This is probably where Bob and I disagree. Personally I don’t touch ruby, python and java and “those” with a 10 foot pole.

Does he make valid arguments, yes, is agile the solve all solution no.. but agile ideas do come natural and respond faster the feedback loop of product development is much smaller and the managers and clients and customers can “see things” sooner than purly waterfall.. I mean agile is the natural approach of disciplined engineers....waterfall is and was developed because the market was flooded with undisciplined engineers and continues to flood, agile is great for them but only if they are skilled in what they are doing and see the bigger picture of the forest thru the trees.. which is the entire point of waterfall, to see the forest.. the end goal... now I’m not saying agile you only see a branch of a single tree of the forest.. but too often young engineers, and beginners jump on agile because it’s “trendy” or “everyone’s doing it” or whatever the fuck reason. The point is they do it but only focus on the immediate use case, needs and deliverables due next week.

What’s wrong with that?? Well an undisciplined engineer doing agile (no I’m not talking damn scrum shit and all that marketing bullshit).. pure true agile.
They will write code for the need due next week, but they won’t realize that hmm I will have the need 3 months from now for some feature that needs to connect to this, so I better design this code with that future feature in mind...

The disciplined engineer would do that. That is why waterfall exists so ideally the big picture is painted before hand.

The undisciplined engineer will then be frustrated in the future when he has to act like the cool aid man thru the hard pre mature architectural boundaries he created and now needs links or connections that are now needed.

Does moving to agile fix that hell no.. because the undisciplined engineer is still undisciplined.

One could argue the project manager or scrum secretary... (yes scrum secretary I said that right).. is suppose to organize and create and order the features with the future in mind etc...

Bullshit ..soo basically your saying the scrum kid is suppose to be the disciplined engineer to have foresight into realizing future features and making requirements and task now that cover those things? No!
1 scrum bitch focuses too much on pleasing “stake holders” especially taken literally in start ups where the non technical idiots are too involved with the engineering team and the scrum bastard tries to ass kiss and get everything organized and tasks working so the non technical person can see pretty things work.

Scrum master is a gate keeper and is not needed and actually hinders the whole process of making a undisciplined engineer into a disciplined engineer, makes the undisciplined engineer into a “forever” code grunt... filling weekly orders of story points unable to see the forest until it’s over because the forest isn’t show to the grunt only the scrum keeper knows the big picture..... this is bad this is why waterfall is needed.

Waterfall has its own problems, But that’s another story for another day..

ANYWAY... soooo where were we ....

Ahh yess....

Clean code..

Is it a good book, yes.. does uncle bobs personality show thru the book .. yes lol.
If you know uncle bob you will understand what I just did with this post lol. I had to tangent ( at least mine was related to the topic) ...

I agree with the principles of the book, I don’t agree with the extreme view point. It’s like religion there’s the modest folks and then there are the extremists. Well he’s the preacher of the cult and he’s on the extreme side.. but that doesn’t mean he’s wrong.. many things he nails... he just hits the nail thru the wall just a bit.

OOP languages are not the solution... high level languages do not solve everything.. pininciples and concepts can be used across the board and prove valuable.. just don’t hold everything up like the 10 commandments of which you cannot deviate from.. that’s the difference here I think..

Good book, just don’t take it as the Bible as a beginner, actually infact DONT read this book as a beginner. Wait a bit learn then reflect by reading this.

My boss uses agile development so he doesn't has to think about use cases he wants to be covered by the application.

He's just throwing in a "design" (an image that is probably created with Paint) without any further specifications and inconsistent elements, let the developer work two days on it, see the outcome, complains why it's not how he wanted it to be and then starts thinking how the feature should be integrated in the app and notices that his "requirements" from the image could not provide any advantage or usage at all for the user of the application. Asking for clarification before starting to work just leads to spongy statements or silence when he notices that he didn't think through to the end.

Sad is that this has not happened only once but is usually the way a new feature is developed...

Some of you know I'm an amateur programmer (ok, you all do). But recently I decided I'm gonna go for a career in it.

I thought projects to demo what I know were important, but everything I've seen so far says otherwise. Seems like the most important thing to hiring managers is knowing how to solve small, arbitrary problems. Specifics can be learned and a lot of 'requirements' are actually optional to scare off wannabes and tryhards looking for a sweet paycheck.

So I've gone back, dusted off all the areas where I'm rusty (curse you regex!), and am relearning, properly. Flash cards and all. Getting the essentials committed to memory, instead of fumbling through, and having to look at docs every five minutes to remember how to do something because I switch languages, frameworks, and tooling so often. Really committing toward one set of technologies and drilling the fundamentals.

Would you say this is the correct approach to gaining a position in 2020, for a junior dev?
I know for a long time, 'entry level' positions didn't really exist, but from what I'm hearing around the net, thats changing.

Heres what I'm learning (or relearning since I've used em only occasionally):

* Git (small personal projects, only used it a few times)
* SQL
* Backend (Flask, Django)
* Frontend (React)
* Testing with Cypress or Jest

Any of you have further recommendations?

Gulp? Grunt? Are these considered 'matter of course' (simply expected), or learn-as-you for a beginner like myself?

Is knowing the agile 'manifesto' (whatever that means) by heart really considered a big deal?

What about the basics of BDD and XP?

Is knowing how to properly write user-stories worth a damn or considered a waste of time to managers?

Am I going to be tested on obscure minutiae like little-used yarn/npm commands?

Would it be considered a bonus to have all the various HTTP codes memorized? I mean thats probably a great idea, but is that an absolute requirement for newbies, or something you learn as you practice?

During interviews, is there an emphasis on speed or correctness? I'm nitpicky, like to write cleanly commented code, and prefer to have documentation open at all times.
Am I going to, eh, 'lose points' for relying on documentation during an interview?

I'm an average programmer on my good days, and the only thing I really have going for me is a *weird* combination of ADD and autism-like focus that basically neutralize each other. The only other skill I have is talking at people's own level to gauge what they need and understand. Unfortunately, and contrary to the grifter persona I present for lulz, I hate selling, let alone grifting.
Otherwise I would have enjoyed telemarketing way more and wouldn't even be asking this question. But thankfully I escaped that hell and am now here, asking for your timeless nuggets of bitter wisdom.

What are truly *entry level* web developers *expected* to know, *right out the gate*, obviously besides the language they're using?

Also, what is the language they use to program websites? It's like java right? I need to know. I'm in an interview RIGHT now and they left me alone with a PC for 30 minutes. I've been surfing pornhub for the last 25 minutes. I figure the answer should take about 5 minutes, could you help me out and copypasta it?

Okay, okay, I'm kidding, I couldn't help myself. The rest of the questions are serious and I'd love to know what your opinions are on what is important for web developers in 2020, especially entry level developers.

Changing instances to arrays. So we've all had this issue:

Option 1 was the most flexible and abstract option where a lot of functionality could be built on this.

Option 2 was the fastest solution, that would solve only specific problems.

The whole Agile philosophy points to option 2. The problem is that clients will always want to add that functionality in option 1, and changing requirements makes us lose time, the precious resource that managers supposedly cherish, yet they always want us to choose the fast option.

We're at that point where the client wants to add functionalities, but since we already built with the previous requirements in mind. Ugh.

Changing instances to arrays.

Into a bunch of open source hogging meat heads because no one likes paying for things their own peers toil days and nights creating and creating more under documented over expensive licensed stuff (because agile) while throwing buzzwords to clients just make business while simultaneously choking the life out of underpaid overworked devs and engineers with the skill of running away from responsibility trying to save their own skin with the inept ability to look like a hero/King at the end of the day with a single mail sent with psychic communication or the lack thereof with people who are slogging their asses off to fix a problem created to the vulnerabilities and bugs introduced due to the impatience of the same moron who couldn't afford to give his employees/subordinates more time to figure out an elegant solution to a non existent problem created in the confusion of improperly documenting unnecessary requirements of an ignorant or unknowing client who is way too eager to process way too much load with way too less resources all the while whining about lack of features theyre not gonna use.

I made a point to the management that people are unnecessarily reworking things and throwing away. And all products should have a product owner and they should give requirements. So the management called the same guy(who fucking does pointless rewrites in the name of code cleanup) and said come up with a solution. The guy came with a solution of Agile + Jira and a whole fucking process behind it. So guess what, we are having pointless meetings when we can just finish and ship deliverables.

The management successfully founded an efficient way to effectively waste time. Kuddos.

Random recruiter from LinkedIn sends an “opportunity” in a well stablished German company in Madrid ..

.. has three entries in requirements for jquery, associated with, and I quote “OOP, Object Programming, and other frameworks” ..

Goes on to require knowledge of “css, scss and saas”, along with “Don HTML” ..

And requests “experience with the principles of agile user interface methodologies” ..

And Angular 1 ..

How would you respond to this one!?

I actually did, corrected the mistakes, told what other mistakes were at the differences between libraries and frameworks, .. and that I don’t like Angular and I’m not interested in learning the old one at all ..

Long post, TLDR: Given a large team building large enterprise apps with many parts (mini-projects/processes), how do you reduce the bus-factor and the # of Brent's (Phoenix Project)?

# The detailed version #

We have a lot of people making changes, building in new processes to support new flows or changes in the requirements and data.

But we also have to support these except when it gets into Production there is little information to quickly understand:
- how it works
- what it does/supposed to do
- what the inputs and dependencies are

So often times, if there's an issue, I have to reverse engineer whatever logic I can find out of a huge mess.

I guess the saying goes: the only people that know how it works is whoever wrote it and God.

I'm a senior dev but i spend a lot of time digging thru source code and PROD issues to figure out why ... is broken and how to maybe fix it.

I think in Agile there's supposed to be artifacts during development but never seen em.

Personally whenever i work on a new project, I write down notes and create design diagrams so i can confirm things and have easy to use references while working.

I don't think anyone else does that. And afterwards, I don't have anywhere to put it/share it. There is no central repo for this stuff other than our Wiki but for the most part, is like a dumping ground. You have to dig for information and hoping there's something useful.

And when people leave, information is lost forever and well... we hire a lot of monkeys... so again I feel a lot of times i m trying to recover information from a corrupted hard drive...

The only way real information is transferred is thru word of mouth, special knowledge transfer sessions.

Ideally I would like anything that goes into PROD to have design docs as well as usage instructions in order for anyone to be able to quickly pick it up as needed but I'm not sure if that's realistic.

Even unit tests don't seem to help much as they just test specific functions but don't give much detail about how a whole process is supposed to work.

Dev goals for 2022? Best and worst DX in the past?

Wish to prioritize customers with useful business goals who are open to sustainable web dev, usability and accessibility.
Want to use even more CSS and find a way to use new features like parent selectors without sacrificing compatibility.

Continue learning and using Symfony, but also continue with my full-stack side project using JS or even better TypeScript for the backend also for the backend.

Best developer experience: getting new customers for my own business after leaving a company last winter.

Worst developer experiences:

Corporate customers with large budgets and design agencies seem to fancy all the antipatterns I thought bad and obsolete, like carousel content, animations everywhere, and autoplay videos on the home page. Poorly written, poorly thought, and sometimes contradictory, requirements. Customers and agencies changing their mind halfway through a project.

"Agile" daily meetings, not giving devops necessary repository permissions, and making Webpack mandatory for no real reason.

I’m currently working 2 jobs with over 60 hour work weeks in addition to my own SaaS company.

One job is full-time 40 hours, where I am a mid level developer and I just do the waterfall of tickets that is assigned to me. This place is unorganized and has almost no communication within the team.

The second job I am the Senior Dev and project lead. It’s a contract position that I put 20+ hours in on the evenings and weekends. Agile methodology, with a modern tech stack and I promote excellent communication as well as documenting everything.

I’m in a unique position because I’m able to see these differences and compare them side by side. My full-time job doesn’t really know about the second job. I get my work done, and that’s all that matters. This place is a mess. The project lead (CTO) is a helicopter boss that sticks his nose up at any type of formal documentation and practices. No tests are written.. no SIPs or deployment docs.. no stand ups or anything. I must also mention this team has 5 developers and a QA.. my team is only 2 developers and a QA. We get through tickets much faster.. it helps when I go over every single ticket that is created and add requirements and images..

I guess my point is... I’m about to be a full-time contractor because I can’t take this unprofessionalism anymore.

Just because these formalities technical take longer. It does decrease actual time spent developing a project. Spending a couple of hours on tests and requirements can save you days of back and forth in the future. Not to mention... document.. everything.

Any of you are annoyed by your non-technical manager work practices?

Every release I feel like our manager's goal is to have our planning and results look good in front of higher management, no matter if it is true or not.

Oh this big task could not be done because we had to plan 4 months in advance with no info and poorly done requirements? Well let's just push it to the next release we can't have unfinished tasks logged in.

Oh we don't have time to work on tech debt and refactoring, there are too many features and bugfixes to do. Well maybe that is why there are so many bugs, eh?

Oh your automated test results need to all look perfect, does not matter if your test are even good or actually doing anything in the first place, as long as it passes.

Also, I was promised agile and got a waterfall-like bullshit process instead that barely works.

Anyways just morning rambling.

Ha! There's nothing like listening to a couple of crotchety devs talking shit about agile for half an hour, just to have a junior dev bust into the room and frantically exclaim "we have to start over from scratch again!" Apparently, someone didnt fully understand the requirements... 😉

TLDR, need suggestions for a small team, ALM, or at least Requirements, Issue and test case tracking.

Okay my team needs some advice.

Soo the powers at be a year ago or so decided to move our requirement tracking process, test case and issue tracking from word, excel and Visio. To an ALM.. they choice Siemens Polarion for whatever reason assuming because of team center some divisions use it..

Ohhh and by the way we’ve been all engineering shit perfectly fine with the process we had with word, excel and Visio.. it wasn’t any extra work, because we needed to make those documents regardless, and it’s far easier to write the shit in the raw format than fuck around with the Mouse and all the config fields on some web app.

ANYWAY before anyone asks or suggests a process to match the tool, here’s some back ground info. We are a team of about 10-15. Split between mech, elec, and software with more on mech or elec side.
But regardless, for each project there is only 1 engineer of each concentration working on the project. So one mech, one elec and one software per project/product. Which doesn’t seem like a lot but it works out perfectly actually. (Although that might be a surprise for the most of you)..
ANYWAY... it’s kinda self managed, we have a manger that that directs the project and what features when, during development and pre release.

The issue is we hired a guy for requirements/ Polarion secretary (DevOps) claims to be the expert.. Polarion is taking too long too slow and too much config....

We want to switch, but don’t know what to. We don’t wanna create more work for us. We do peer reviews across the entire team. I think we are Sudo agile /scrum but not structured.

I like jira but it’s not great for true requirements... we get PDFs from oems and converting to word for any ALM sucks.. we use helix QAC for Misra compliance so part of me wants to use helix ALM... Polarion does not support us unless we pay thousands for “support package” I just don’t see the value added. Especially when our “DevOps” secretary is sub par.. plus I don’t believe in DevOps.. no value added for someone who can’t engineer only sudo direct. Hell we almost wanna use our interns for requirements tracking/ record keeping. We as the engineers know what todo and have been doing shit the old way for decades without issues...

Need suggestions for small team per project.. 1softwar 1elec 1mech... but large team over all across many projects.

Sorry for the long rant.. at the bar .. kinda drunk ranting tbh but do need opinions...

Right guys and gals, I need your opinions.

Recently was approached by a recruiter who thought I’d be a good fit for a role, a role that is a step up from senior dev but without moving into people / project management.
More like a bridge between architects and senior devs.

I thought what the hell, why not. So I agreed to go for it.
It could be quite a decent payrise (though that wasn’t my motivation for going for it) and I like the idea of doing more mentoring, design and research than I do now. It would involve stuff like learning new tech, coming up with examples and implementations of how the dev team need to use it to churn out user stories.

For the last few years I’ve been mainly a back end developer, which didn’t start by choice and I always liked to be full stack.

But the recruitment process for this role has been quite slow (number of reasons) and since then I’ve been given a new piece of work at my current employer doing some greenfield angular work, plus the c# back end.

I’m really, really enjoying this angular work. Haven’t done it for a while and it feels great to get back into it. Seem to be picking it back up with no problems, like the old magic is still there.
Also the money at my current place is good enough.

So now I’m wondering if I should bail on this other role in favour of seeing this out and maybe going back to being full stack (tho for reasons I’ll outline below in the long term that might have to be elsewhere)

But I’m also trying to remind myself that up until enjoying this work there’s a reason I decided to go for this other role.
Current place is a small company that has no project management process. It’s chaos, and everything’s an emergency. There are no requirements for anything, not enough people etc. No one has a clue how to run an IT project.
The one thing we do have is good development practices in our team and we have been greenfield for the last 12 months working on a new product. But we do tend to be pigeon holed into looking after a specific service/area.

But this new place if I got the role, is a bigger company (I’ve worked in small, medium and massive companies so I know what the difference is like), they’re a household name, they have resources for learning, putting people through aws certs, etc. They give people time each week to invest in themselves. Much more agile.
And thinking about it now you don’t often see a role that allows you to ‘move up’ without having to take on people/project management and still having time to be hands on.
(Just maybe more hands on with strategic work than delivering user stories for business as usual)

So just in general, what do you think?

Has anybody experience with Scrum in small web development agencies? Especially estimating stories with story points instead of hours/days?
We have a new junior project manager, without any practical experience working agile, who wants to establish scrum because what he read about it sounded so good... I already worked agile with kanban before and I loved it, but I only have little experience with scrum.
I think scrum, or agile in general, won't work with the clients we have. Most of the time, our clients have a fixed deadline, a fixed budget (either money or time) and they know their requirements, so there is no much room for beeing agile.
Regarding story points, I just adding an unneccessary layer of abstraction, because the customer wants to know how long a specific feature takes. Sure, story points are just another, more dynamic unit for time, but then why nut estimate in static time unit in the first place? Another fear I have, is that some devs may be more ignorant regarding deadlines and expectations on customers side. "yeah I'm working for 10 days on this story, but it's 8 points!" instead of informing the project manager "Currently I spend 2 days on this feature, we estimated 3 days, but it seems I need 3 days more".

Maybe I shouldn't be worried, but it would be great if you could share your experience and learnings. Thanks in advance!

It seems that my barometer for whether I would stay long in a company is roughly 1.5 years. Because apparently that's how long it takes to gauge if:

(a) The work I'm doing is fulfilling or self-satisfying
(b) My colleagues make work a fun and challenging experience
(c) My bosses are people I can be proud to work for.

Right now, the tally thus far:

(a) The work is half crap, supporting old code (fuck Swig and Architect, by the way) or fixing bugs on old projects. New projects are always mismanaged, and I mean ALWAYS (let's do Agile and create tickets but hey the requirements are still in progress so do start anyway and we'll file everything as bug tickets until they're done)

(b) I'm sure it's an effect of going remote working for the last few months, but I'm feeling detached from my team. It's fine I guess.

(c) My manager is okay, he's a good guy who listens and is also technical so we get along. But his boss (who oversees several teams. including ours) is a total prick who loves to insult people at their expense as a joke. He knows nobody's gonna talk smack back so he just does it without repercussions.

I'll probably see if I can move around internally to a different division since the pandemic makes it difficult to find work externally. I'm grateful I have a job, but I shouldn't have to feel like I owe the company for that at the cost of my personal happiness.

Just gotta #survive2020 I suppose.