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.

Best part about the covid19 manufactured crisis?
Liquor stores deliver. Worst part about liquor stores delivering? Needing to use their shoddy websites.

I've been using a particular store (Total Wines) since they're cheaper than the rest and have better selection; it's quite literally a large warehouse made to look like a store.

Their website tries really hard to look professional, too, but it's just not. It took me two days to order, and not just from lack of time -- though from working 14 hour days, that's a factor.

Signing up was difficult. Your username is an email address, but you can't use comments because the server 500s, making the ajax call produce a wonderfully ambiguous error message. It also fades the page out like it's waiting on something, but that fade is on top of the error modal too. Similar error with the password field, though I don't remember how I triggered it.

Signing up also requires agreeing to subscribe to their newsletter. it's technically an opt-in, but not opting-in doesn't allow you to proceed. Same with opting-in to receiving a text notification when your order is ready for pickup -- you also opt-in to reciving SMS spam.

Another issue: After signing up, you start to navigate through the paginated product list. Every page change scrolls you to the exact middle of the next page. Not deliberatly; the UI loads first, and the browser gets as close as it can to your previous position -- which was below that as the pagination is at the bottom -- and then the products populate after. But regardless of why, there is no worse place to start because now you must scroll in both directions to view the products. If it stayed at the very bottom, it would at least mean you only need to scroll upwards to look at everything on the page. Minor, but increasingly irritating.

Also, they have like 198 pages of spirits alone because each size is unique entry. A 50ml, 350ml, 500ml, 750ml, 1000ml, and 1750ml bottle of e.g. Tito's vodka isn't one product, it's six. and they're sorted seemingly randomly. I think it's by available stock, looking back.

If you fancy a product, you can click on it for a detail page. Said detail page lists the various sizes in a dropdown, but they're not sorted correctly either, and changing sizes triggers a page reload, which leads to another problem:

if you navigate to more than a few pages within a 10 or so second window, the site accuses you of using browser automation. No captcha here, just a "click me for five seconds" button. However, it (usually) also triggers the check on every other tab you have open after its next nagivation.

That product page also randomly doesn't work. I haven't narrowed it down, but it will randomly decide to start failing, and won't stop failing for hours. It renders the page just fine, then immediately replaces it with a blank page. When it's failing, the only way to interact with the page is a perfectly-timed [esc], which can (and usually does) break all other page functionality, too. Absolutely great when you need to re-add everything from a stale copy of your signed-out cart living in another tab. More on that later. And don't forget to slow down to bypass the "browser automation" check, too!

Oh, and if you're using container tabs, make sure to open new tabs in the SAME container, as any request from the same IP without the login cookie will usually trigger that "browser automation" response, too.

The site also randomly signs you out, but allows you to continue amassing your cart. You'd think this is a good thing until you choose to sign in again... which empties your cart. It's like they don't want to make a sale at all.

The site also randomly forgets your name, replacing it with "null." My screen currently says "Hello, null". Hello, cruft!

It took me two days to order.
Mostly from lack of time, as i've been pulling 14 hour shifts lately trying to get everything done. but the sheer number of bugs certainly wasted most of what little time i had left. Now I definitely need a drink.

But maybe putting up with all of this is worthwhile because of their loyalty program? Apparently if you spend $500, you can take $5 off your next purchase! Yay! 1%! And your points expire! There are three levels; maybe it gets better. Level zero is for everyone; $0 requirement. There are also levels at $500 and $2500. That last one is seriously 5x more than the first paid level. and what does it earn you? A 'free' magazine subscription, 'free' classes (they're usually like $20-$50 iirc), and a 'free' grab bag (a $2.99 value!) twice per month. All for spending $2500. What a steal. It reminds me of Candy Crush's 3-star system where the first two stars are trivial, and the third is usually a difficult stretch goal. But here it's just thinly-veiled manipulation with no benefit.

I can tell they're employing some "smarketing" people with big ideas (read: stolen mistakes), but it's just such a fail.

The whole thing is a fail.

Let me tell you how shit flies in Aerospace&Defense companies in certain place in on earth

1. Your dev. PC is isolated from the internet. You can not download any software/library etc directly. "Legal" way takes literally days and you must all effort for it to work. I will not discuss the details of legal way but it is not asking IT team to download it for you, you do it yourself.

2. You use an archaic requirement standard that is somehow used by all other similar companies too. These companies f*ck each other in the arse when they are working on projects together(hiding details from each other which is necessary most of the times etc.) but they were kind to each other when it came to share shitty req. standard.

3. When you try to switch to new requirement standard, you waste weeks only to amend the old one, because everyone is using old one for all projects, so changing it would upset old guards in the company(which are people works in same project for 10 years, no personal development)
4. You came 1 minutes late, you fill the "minutely permission" form.

5. You already work long hours per day and they remove your small breaks during day, because developers use those breaks longer than intended(I wonder what might be the reason...)

6. A technology can not be adopted into current projects even it has objective advantages proven many times in the outer world, because old guards(developers), IT team and configuration management guys(poor man's dev ops role sometimes) can not change their ways.

I hate this shit...

I'm extremely lucky I'm not violent person. What happened today for some reason just completely pissed me off. I'm not sure why it got under my skin so much, but I feel completely disrespected.

I went to our marketing person's office to discuss a basic requirement for our api. Very simply, we have a lot of old shitty date that doesn't have a lot of fields filled out (worse yet, some are simply bogus values like crazy random dates and whatnot).

She put in a ticket claiming our most recent change started changed the creation dates to be empty. Easy enough to disprove, because the marketing software we have shows a records of all the edits for each contact, and if it came from our api it'll be labeled as "Web API". So of course I check the example contacts she give us, and there's no history of changes, meaning they never had the date to begin with (which is correct, as until now we didn't track creation date WHICH IS NOT MY DECISION. So dude 10 years ago probably made that decision).

So I start asking what exactly we're using it for. She does an absolutely horrible job of describing it and keeps telling me "no you absolutely have to be able to do all this, it's our requirements". By "this" she wants me to magically give all these contacts correct creation dates after the fact.

Eventually she gets the whole campaign idea out and I point, politely, that they're probably violating GDPR. She starts yelling saying her and her boss have been doing marketing for years and they know what they're doing. So I (less politely this time) said that's fine, I just want to talk with her boss to make sure he understands he's in the grey area and that if I'm the one building this, I'm kind of liable as well.

She clearly didn't like that, but I thought whatever, let's just agree on some requirements and I'll pass it on to my boss (who genuinely shits on her every single day and is constantly saying she never knows what she's doing).

So I go back , do some work. A little later I have to go print something off which is next to her office. Her door is shut, but I can hear her from down the hall yelling at someone about the conversation we just had. She actually starts mocking me. Doing the "stupid person" voice. This goes on for longer than our conversation.

Like I said, I know I'm right and she's just venting because she doesn't want to admit she's made a mistake. But for some reason it just completely broke me. I'm new but up until this point everyone had been pretty open about how they feel about me and my co-worker. But she just didn't need to go that bloody far.

This is something that happened 2 years ago.

1st year at uni, comp sci.

Already got project to make some app for the univ that runs in android, along with the server

I thought, omg, this is awesome! First year and already got something to offer for the university 😅
(it's a new university, at the time I was the 2nd batch)

Team of 12, we know our stuffs, from the programming POV, at least, but we know nothing about dealing with client.

We got a decent pay, we got our computers upgraded for free, and we even got phones of different screen sizes to test out our apps on.

No user requirement, just 2-3 meetings. We were very naive back then.

2 weeks into development, Project manager issues requirement changes

we have a meeting again, discussing the important detail regarding the business model. Apparently even the univ side hadn't figure it out.

1 month in the development, the project manager left to middle east to pursue doctoral degree

we were left with "just do what you want, as long as it works"

Our projects are due to be done in 3 months. We had issues with the payment, we don't get paid until after everything's done. Yet the worse thing is, we complied.

Month 3, turns out we need to present our app to some other guy in the management who apparently owns all the money. He's pleased, but yet, issued some more changes. We didn't even know that we needed to make dashboard at that time.

The project was extended by one month. We did all the things required, but only got the payment for 3 months.

Couldn't really ask for the payment of the fourth month since apparently now the univ is having some 'financial issues'.

And above all: Our program weren't even tested, let alone being used, since they haven't even 'upgraded' the university such that people would need to use our program as previously planned.

Well, there's nothing to be done right now, but at least I've learned some REALLY valuable lesson:

1. User Requirement is a MUST! Have them sign it afterwards, and never do any work until then. This way, change of requirements could be rejected, or at least postponed

2. Code convention is a MUST! We have our code, in the end, written in English and Indonesian, which causes confusion. Furthermore, some settle to underscore when naming things, while other chooses camel case.

3. Don't give everyone write access to repository. Have them pull their own, and make PR later on. At least this way, they are forced to fix their changes when it doesn't meet the code convention.

4. Yell at EVERYONE who use cryptic git commit message. Some of my team uses JUST EMOTICONS for the commit message. At this point, even "fixes stuffs" sound better.

Well, that's for my rant. Thanks for reading through it. I wish some of you could actually benefit from it, especially if you're about to take on your first project.

Can't remember how many times I had to change project structure just because they provided wrong/misleading/half-ass requirement

Project management site, exclusively for use by our team and clients.

- The client creates a new project.
- They list the requirements, supplying all the necessary files and content.
- We challenge any stupid stuff by offering alternative solutions.
- We all sign off on the requirements and no more are allowed to be added or modified. If they forgot anything, it's on record who's to blame.
- We estimate time and cost to complete the build.
- If they accept, we finally begin the work
- At each stage of every requirement, we mark the status as pending, in progress, ready for testing and delivered.

Much less stress due to minimising change requests. Plus easier to follow than an email chain and easier for them to use than a jira portal.

Job posting: "we require 1.5 years of experience in iOS development"

Also job posting: *doesn't mention a requirement for a degree*

Me: "Cool, this looks exactly like a job for me, I'll send them my résumé!

Recruiter returns to me a day after with this:

"You said you have no work experience, we said in the posting that you need to have 1.5 years of work experience"

THE JOB POSTING DOES NOT MENTION THIS ANYWHERE, THEY ONLY MENTION EXPERIENCE IN IOS DEVELOPMENT

WHY MAKE IT SO AMBIGUOUS AND THEN CHANGE YOUR STANCE

When I finally get a fucking response from a recruiter after sending my résumé to dozens upon dozens of companies, it's a bullshit response.

FUCK YOU.

Note: I am aware of the massive amount of AltRant crashes, I am sorry for making it worse. I need to work on 2 more major final tests that I must pass, but I think I will start fixing some of the crashes today.

This was not exactly the worst work culture because the employees, it was because the upper level of the organization chart on the IT department.

I'm not quite sure how to translate the exact positions of that chart, but lets say that there is a General Manager, a couple of Area Managers (Infrastructure, Development), some Area Supervisors (2 or 3, by each area), and the grunts (that were us). Anyway, anything on the "Manager" was the source of all the toxicity on the department.

First and foremost, there was a lack of training for almost any employee. We were expected to know everything since day-1. Yes, the new employees had a (very) brief explanation about the technologies/languages were used, but they were expected to perform as a senior employee almost since the moment they cross the door. And forget about having some KT (Knowledge Transfer) sessions, they were none existent and if they existed, were only to solve a very immediate issue (now imagine what happened when someone quit*).

The general culture that they have to always say "yes" to the client/customer to almost anything without consulting to the development teams if that what was being asked to do was doable, or even feasible. And forget about doing a proper documentation about that change/development, as "that was needed yesterday and it needs to be done to be implemented tomorrow" (you know what I mean). This contributes to the previous point, as we didn't have enough time to train someone new because we had this absurd deadlines.

And because they cannot/wanted to say "NO", there were days when they came with an amount of new requirements that needed to be done and it didn't matter that we had other things to do. And the worst was that, until a couple of years (more or less), there was almost impossible to gather the correct requirements from the client/user, as they (managers) "had already" that requirement, and as they "know better" what the user wants, it was their vision what was being described on the requirements, not the users'...

And all that caused that, in a common basis, didn't have enough time to do all this stuff (mainly because the User Support) causing that we needed to do overtime, which almost always went unpaid (because a very ambiguous clause of the contract, and that we were "non-union workers"**). And this is my favorite point of this list, because, almost any overtime went unpaid, so basically we were expected to be working for free after the end of the work day (lets say, after the 17:00). Leaving "early" was almost a sin for the managers, as they always expected that we give more time to work that the indicated on the contract, and if not, they could raise a report to HR because the ambiguous clause allowed them to do it (among other childish things that they do).

Finally, the jewel of the crown, is that they never, but never acknowledge that they made a mistake. Never. That was impossible! If something failed on the things/systems/applications that they had assigned*** it was always our fault.

- "A report for the Finance Department is giving wrong information? It's the DBA's fault**** because although he manages that report, he couldn't imagine that I have an undocumented service (that runs before the creation the report) crashed because I modified a hidden and undocumented temporal table and forgot to update that service."

But, well, at least that's on the past. And although those aren't all the things that made that workplace so toxic, for me those were the most prominent ones.

-

* Well, here we I live it's very common to don't say anything about leaving the company until the very last day. Yes, I know that there are people that leave their "2-days notice", but it's not common (IMHO, of course). And yes, there are some of us that give a 1 or 2-weeks notice, but still it's not a common practice.

** I don't know how to translate this... We have a concept called "trusted employee", which is mainly used to describe any administrative employee, and that commonly is expected to give the 110% of what the contract says (unpaid overtimes, extra stuff to do, etc) and sadly it's an accepted condition (for whatever reasons). I chose "non-union workers" because in comparison with an union worker, we have less protections (besides the legal ways) regarding what I've described before. Curiously, there are also "operative workers", that doesn't belong to an union, but they have (sometimes) better protections that the administrative ones.

*** Yes, they were in charge of several systems, because they didn't trust us to handle/maintain them. And I'm sure that they still don't trust in their developers.

**** One of the managers, and the DBA are the only ones that handle some stuff (specially the one that involves "money"). The thing that allows to use the DBA as scapegoat is that such manager have more privileges and permissions than the DBA, as he was the previous DBA

Once we got an urgent requirement to add double hashing the password in a web application. It had to go to the production ASAP. The developer which was working on it, added 2 alerts in Javascript to display entered password and encrypted password. Finally change was ready to deploy but in hurry she forgot to remove the alerts. In rush and excitement, that change was shipped to the production. The alert says 'your password is 123', 'your password is xyz'.

After some time got phone calls from users and manager. Manager said, 'how the hell our application got HACKED? If anything happens to..........'. To cut it short, he was furious. We knew exact reason and solution. Didn't take couple of minutes to resolve this issue.

But it was funny mistake and that released that days pressure off.

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

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

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

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

Its too boring.

Don't expect requirements that will "never change, guaranteed" to actually "never change, guaranteed"

When college professors want students to do college portal's works.
ACCEPT THE FUCKING WORK.

DO NOT CHANGE THE INITIAL REQUIREMENT WHILE I'M WORKING ON IT.

DO NOT CHANGE MY WORK WITHOUT ASKING ME OR AT THE LEAST NOTIFYING ME.

YOUR PORTAL LOOK HORRIBLE NOW WITH SHIT TIER MENU WHICH I SUGGESTED IN THE FIRST PLACE THAT IT WOULD LOOK GOOD THIS WAY. AND NOW YOU'VE MADE IT LOOK SO BAD MY EYES HAVE CANCER.

tl;dr - why you no read this?

Here I am pondering why I continue to return to my job everyday when we are currently at month 13 of a 4 month project... yea let that set in for a minute... which is still at least 3-4 months away from being deployed due to annual leave of key stake holders and the whole Christmas period creeping up and things just not going as planned every step of the way.

There's no greater demotivater - is that even how you spell it - then being stuck in a project for so long you really just don't give a shit if it works or not anymore.

This has gone from a simple - relatively speaking - project to some monolithic mayhem of requirement changes and process adjustments, that have not only delayed our team, but 3rd party vendors needing to change things as well, or the requirements being wrong early so when you get up to business testing it's like "nope, that's not what we wanted" .... despite all the sessions of you personally giving the PM all the damn requirements.

But in saying that, they (3rd party) aren't innocent either, we have found nothing but issue after issue with their product since we started this project that who ever signed off on going forward with the thing should have been shot from both sides - it's not designed for the scale we will be using it yet we didn't find that out till we got so far into the rabbit hole we had a chance to be able to do load testing.

Meh, guess I'll go to work Monday and spend another week in misery trying to deliver something that just doesn't want to know what the finish line is.

dev, ~boring

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/rant

I am a bad developer. I know nothing. I had a very simple requirement just to change the strings.
I couldn't collect all the requirements. I connected with PM offline, slow replies and miscommunications. Ahh!! How will I be shipping bigger projects? I have 3 years of development, in my last company we worked totally different though.
So, at the time when I thought I will be raising a PR I am stuck on the requirements.
I am a dumb shit. I can't do anything right. A simple requirement I am not able to deliver. I am so embarassed. :(

PM wrote a really high-level requirement doc and asked me about estimates.

Me: Well, functionality-wise it will take 4-5 days provided the design is ready.

PM: Our designers are really full on schedule; Just do it! Expand your creativity. I believe in your taste of UX

Me: Listen, the implemented design will take much more time to change if we go back and forth. It's better to revise on the designer's screen.

PM: Oh don't be so modest! I trust you already. Just focus on the functionality, get it done first. For the design we'll talk about it later. Move fast and break things!

Me: ..Sigh. This is gonna end up badly.

We've recently employed a new lead dev that seems to have a problem in that his solution is always the correct solution.

On a typical day, whenever I push code up for review via pull request, every single ticket I work on, he has something that has to change which doubles the amount of time of each ticket.

I'd be fine with this if the other 2 developers also think he's a bit of a headache in terms of his opinion but a lot of the time, there is always.. ALWAYS something that has to change because his method is better than mine.

For example, just now I pushed up some code that literally just adds in the user's email to the view which is already in the store for that action/effect anyway. I added one line of HTML.

He comments saying that I need to change the way it gets the email by doing a different request in the effect, to get the current user id, and from that match it against the email address, and THEN display it in the view.

This ticket took me 5 minutes. He's making me make it 30-60 minutes (to understand his requirement and implement it).

Is this normal? Am I over reacting?

Opinions please!

!rant
So on the last day before launch our latest feature I'm informed that a requirement was missed and it had to be implemented before go live otherwise the business didn't want the feature. The feature in question was pretty drastic and basically required a scheme rewrite, new tables, etc. So I spent the entire day making the change.

Thankfully I pushed the whole project for good code coverage. Therefore, all I had to do when I was done was run all of our tests and make sure they passed. *warm fuzzy feelings*

Holy shit sometimes I hate my job. Current assignment: translate a C++ COM class to C#. Requirement: interface should not change. I ask the other team using this interface to ask me any questions so I can address their concerns. First FUCKING thing they ask for: a diagram explaining how to access the interface. For. Fuck. Sake. The goddamn thing is not changing. At all. I have said that to every stakeholder every time. It's a changed reference and a tweak to some calls to make them .Net calls. Why am I redocumenting something that was documented years ago?

2 years back when I was onshore, we were in the bad situation due to the size and complexity of handling big webserivces simulators. A single change makes the build red hence the face of other developers too.

These simulators were created using J2EE and VM templates 5 years back. With the time, application and data size grown. We were supposed to maintain consistensy in dummy data accross the applications. But some programmers made a copy of these simulators to finish their applications fast and made the situation worst.

Finally one of the team member dare to use stubby4j to solve this problem. Choosing the stubby4j was a good decision as it was the specialized tool written to create simulators only. But as the stubby4j was not having all the features a simulator need, he customized it's build for our simulators. All the team members were happy.

After few weeks, I picked a story to transform other simulators using stubby4j. The story was previously closed as it was hard to implement in stubby4j. I ingonred the comment and started working on. I spent 2 weeks but couldn't solve the problem. I read the comment in between but It was very late to take the step back. I was not able to give proper status update in the daily standup. Other team members (working from offshore) were thinking that I'm just passing the time. However my manager handled the situation very well and asked if I need some help.

This was friday, I took the leave as it was my wife's birthday. We couldn't go out due to the bad weather. I was thinking about the code all the time. Hence I started to write a new utility to handle all the requirement a webseervice simulator need. I took 2.5 days to complete it. On Tuesday, I demoed it to the whole team. And published it as an opensource application "STUBMATIC". In few weeks I received the good response from other teams as well.

I'm a full time open source developer now.

A customer asks for a change request or a bug fix and it results in creating a ticket for that.
It's the process and how it works in most places but after you finish with the task and fix the same customer who provided you with the requirements will request that you share the steps on how to test the fix or the feature.
I'm not speaking about the data preparation or required configuration. I mean a step-by-step instruction on how the tester/QA will test it.
It's driving me mad!! So a way to counterplay this stupid requests, I provide the happy path and what to expect. And in case, they stumbled on a bug later in production, I can easily say "It was approved by your testing team and that's a new requirement ;)"

I prefer it doing 2 tasks parallely during the initial phase of requirement gathering and design phase.(makes more sense if you are working extremely new system and framework)
1. Keep collecting requirements from clients and understand them.
2. Collect different designing aspects for the project and parallely, build a POC for 2 purpose: to get hands into the new Framework and also as a demo to clients. Working on POC helps in 3 ways: Improving understanding of requirement, improving framework knowledge, and playing around with code whenever bored of designing and reading tons of existing designs..
3. Once primary requirements are clear and fixed, analyse all different designs, if possible I setup meetings with senior devs, principal engineers (they help a lot when it comes to reviews on scalability and reliability of a design)
4. The above design is mostly architectural level. Once design is fixed, then I start taking each component and prepare a detailed implementation design. (Notice that whenever I am bored of designing, I spend sometime in building POC)
5. In detail design, I focus on modularity and flexibility. Anything defined should have getters and setters for example. This will help you reuse your code. Keep the interface between components in your design as generic as possible, so that in case your MySQL is change to Postgre or NoSQL, your design should be able to adapt new features..
6. Instead of building entire project, define feature targets and deliver small features.. this will help you to be in line with the requirements with minimum deviation.

To give you some context, in the past year we have change managers 3 times. Obviously our process (we were trying to follow agile) has suffer the most with all these changes since it seems the managers that have been assigned to us are not really IT people.

We are using TFS (I know...) for our builds and for our scrum and kanban boards, only use developers and QA are really using the board and all the benefits that it provides and the managers are oblivious to what TFS is. I have tried offering them training and workshops but they just don't want to learn.

And now they want us to keep the requirement information on word documents and Excel instead. I'm not sure I can continue my battle against Word/Excel...

I understand they are valuable tools but... Is it really difficult to use a tool that was made specifically for that and it's as easy as filling some text fields and click a button? Why is it so hard to understand that if you want to know the status of a task is as simple as following a link where you can find all the related information?

I think I'm loosing it, even the other developer on my team is in support of using Word... of course the guy doesn't know agile and his cards on the board are shit making him work with QA all the time....

Feel like I'm alone here....

That moment when you work butt off whole month for some requirement and when you finish that, the Email comes saying stop doing that because they want to change their whole platform.(SugarCRM to Salesforce).
Now I have to learn that (Hope it goes well).
I'm happy because "bye bye php!" and little sad because now I've to spend half of my time learning Salesforce.

I am more of a backend guy. I just started coding in frontend too. Now I have to change some of the hardcoded things and those should be come from the backend. Yes this is the requirement.
Don't know how will I do it at this stage 🤔

Shopify sucks. Change my mind.

"The Postmates app is no longer available for download. If you already have the Postmates app installed, you can continue using it until January 10, 2019."

So, if your client built their site so that it depended on this app for a big requirement in their online store fulfillment, you now have to hope that there's another app that could match its capabilities. Or, you have to spend more budget to develop your own so you have 100% control over it.

change requirement drastically!? WTF

You work in a team, for a team to move forward successfully the team should work in sync. A team always has a goal and a plan to get to it. There are times when the team needs to take a different direction therefore the set path should always be available for change because our environments dictate it.

We all have different styles of working and different opinions on how things should work. Sometimes one is wrong and the other is right, and sometimes both are wrong, or actually sometimes both are right. However, at the end of it all, the next step is a decision for the team, not an individual, and moving forward means doing it together. #KickAssTeam

The end result can not come in at the beginning but only at the end of an implementation and sometimes if you’re lucky, during implementation you can smell the shit before it hits the fan. So as humans, we will make mistakes at times by using the wrong decisions and when this happens, a strong team will pull things in the right direction quickly and together. #KickAssTeam

Having a team of different opinions does not mean not being able to work together. It actually means a strong team! #kickAssTeam However the challenging part means it can be a challenge. This calls for having processes in place that will allow the team members to be heard and for new knowledge to take lead. This space requires discipline in listening and interrogating opinions without attachment to ideas and always knowing that YOUR opinion is a suggestion, not a solution. Until it is taken on by the team. #KickAssTeam We all love our own thinking. However, learning to re-learn or change opinions when faced with new information should become as easy to take in and use.

Now, I am no expert at this however through my years of development I find this strategy to work in a team of developers. It’s a few questions you ask yourself before every commit, When faced with working in a new team and possibly as a suggestion when trying to align other team members with the team.

The point of this article, the questions to self!

Am I following the formatting standard set?

Is what I have written in line with official documentation?

Is what I am committing a technical conversion of the business requirement?

Have I duplicated functionality the framework already offers?

I have introduced a methodology, library, heavily reusable component to the system, have you had a discussion with the team before implementing?

Are your methods and functions truly responsible for 1 thing?

Will someone you will never get to talk to or your future self have documentation of your work?
Either via point number 2, domain-specific, or business requirements documentation.

Are you future thinking too much in your solution?

Will future proof have a great chance of complicating the current use case?

Remember, you can never write perfect code that cures every future problem, but what you can do perfectly is serve the current business problem you are facing and after doing that for decades, you would have had a perfect line of development success.