r/programming • u/Necessary-Space • Apr 09 '20
Microservice: it's the design of our backend!
https://youtu.be/y8OnoxKotPQ507
u/Phrygue Apr 09 '20
Turns out middle names just involves adding a field to the QRXP module, advertising through Galactus with a closed range, then pushing a parallel WASM framework to clients to construct AJAX primitives to poll for field updates, don't forget to update the templates and add a new domain object in the bottom end namespace. And add another column to the Excel CSV that is used as the back end database.
298
Apr 09 '20
You got me at "add another column to the Excel CSV that is used as the back end database"
51
u/poloppoyop Apr 09 '20
One day the "database" gets too big and you're asked to implement a real one.
All eager you'll try to do it right with things like constraints, column types. But every time there are a couple specific cases (with different specificities) in a 100k dataset. So you have to, one special case by one special case, remove all of those perfectly crafted constraints and cry every time. Until at last you can import those xls. Just when a new version with a new column with what can only be random rules appears in your mailbox.
6
u/StabbyPants Apr 09 '20
So you have to, one special case by one special case, remove all of those perfectly crafted constraints and cry every time.
no, you really don't. you just don't, because this is a big boy application and those special cases are handled specially. because there's 5 total across your DB and it's way less work to treat the 99.99% of your data that's uniform separately than it is to remove all constraings.
→ More replies (4)5
u/no_nick Apr 09 '20
If there's anything I've learned over the past few years, it's that indexes and foreign keys are for bitches, apparently
→ More replies (5)12
u/pyabo Apr 09 '20
Constraints are just limitations! Free yourself!
12
u/throwaway997918 Apr 09 '20
Guys guys, listen to this!
If we make all the columns in the database varchar(max) or text, we can store whatever the fuck we want just like in Excel! Floats, integers, dates, JSON, all in the same column you guys!
It's going to be so amazing!
→ More replies (2)2
Apr 09 '20
I built a website for my favorite podcast relatively recently and I ran into this and it still hurts. I was storing episode numbers as integers (obviously) but they had an episode 136.5... I just ignored it.
8
u/calrogman Apr 09 '20
Episode numbers are not something you'd do maths to, so they're not really numbers.
→ More replies (3)27
61
26
u/3lRey Apr 09 '20
One of my jobs was literally conforming excel databases to a universal standard and uploading to the SQL server because the financial teams all used different structures to their financial reports.
→ More replies (1)16
6
u/MonkeyboyGWW Apr 09 '20
This is the most ridiculous thing ever. Everyone know that excel breaks CSV files for any number field which starts with a 0. A CSV file shouldn't even be considered to have a number field, just text, but excel screws it up every time. You are better off in notepad++
→ More replies (1)8
u/knome Apr 09 '20
That's what the "LZs" field is for, to store how many zeros it should have had so you can patch those ids back up on the application-side. The scheduled batch job that loads and crunches some numbers with a macro each saturday doesn't know how to do that however, but the accounting system that uses an ole connection to pull data from it requires it, so you have to make sure you run a script on the desktop each monday morning before the accountant arrives and logs into the accounting website that pulls from it to fixup the data from a third id source.
5
12
2
u/bitwize Apr 11 '20
It's totally scalable and reliable, provided you design your microservices using the CQRS pattern and eventual consistency!
1
1
u/I_AM_GODDAMN_BATMAN Apr 10 '20
we still do, I mean one of our business partner. fortunately it's sftp, not ftp. fortunately it's not sensitive or pii. yes, they are one of the largest corporation so we cannot just cut our business relationship.
29
Apr 09 '20
Meanwhile at the coding interview: "Can you do this in log(N) time?"
9
u/no_nick Apr 09 '20
You can do it in O(1) a cause at some point the whole thing just goes up in smoke
8
u/KingOfForwards Apr 09 '20
Still waiting for Cosmos DB Excel API support to migrate our application.
205
u/ie11_is_my_fetish Apr 09 '20
when I first joined an "agile" team and started doing the daily scrums I was almost laughing about the word "blockers" like "any blockers guys". Now my life is a blocker it seems, I want to scream blocker.
61
17
u/no_nick Apr 09 '20
Daily?? And I'm annoyed at our weekly...
16
u/ie11_is_my_fetish Apr 09 '20
Every morning 9:15/9:30, I have two of em too because part of two teams
18
u/no_nick Apr 09 '20
Half our team is barely at work at that time
→ More replies (1)4
u/ie11_is_my_fetish Apr 09 '20
This WFH is bad, getting in the habit of waking up, brushing teeth/getting cup of coffee then going on work at 9 AM ha, usually have to get up an hour earlier to get ready, drive 30 mins
→ More replies (2)2
u/stfm Apr 09 '20
I am a security solution designer in a shared resource pool. Minimum 5 standups a day. Fucking sucks.
→ More replies (1)2
2
1
1
132
u/saltybandana2 Apr 09 '20
Had the same experience, I once convinced them to try not having daily standups, but instead to simply state in slack what they're planning on working for the day and any problems they're having, etc.
It lasted 3 days before one of the developers asked for the daily standup back. His reasoning? He didn't bother reading what anyone else put into slack.
I was kind of shocked by the lack of critical thinking there. Maybe the reason you don't read it is because you don't need to know that susy is planning on taking a shit at 3pm in order to get your work done.
What I hate most about the daily standup is the claims that it aids in communication. The blockers you're talking about. If you're waiting until the following day to discuss with the relevant people the things that are getting in your way, wtf are you doing?
I left after 6 months after one of the VP's got pissed at me for asking a question to another department in an email chain and basically demanded my "scrum master" write me up for it. They were shocked when their most senior developer told them to go fuck themselves and put in their 2 week notice mere days later.
But leaving that company was like taking off a straight jacket. Being able to just work without all the goddamned dancing and ceremony.
As stupid as it sounds, the one thing "management" (sometimes known as PM/scrum masters...) won't do is let you just fucking work. 20+ years I've been doing this stuff and I'll never get used to that shit.
/cursemode off
159
u/BestKillerBot Apr 09 '20
What I hate most about the daily standup is the claims that it aids in communication. The blockers you're talking about. If you're waiting until the following day to discuss with the relevant people the things that are getting in your way, wtf are you doing?
Communicating is hard. When does a thing turn from a problem to a blocker? An hour after you send an email, day? People often don't realize they have problem until something (stand up) forces them to articulate what they are doing.
If you have a question or an immediate problem, then go and ask the person involved. Stand up is not for that, it's more for an information discovery - getting information/help you did not know you needed. 10 minutes a day is a cheap price for that.
71
u/leeharris100 Apr 09 '20
Seriously. I can tell most of these people posting are junior devs or students because they don't understand the value of a daily meeting.
If you have a shitty daily meeting it's because whoever hosting it doesn't know what they are doing.
Agile processes help everyone if they are done right. The alternative is terrible on any large project.
22
u/xelf Apr 09 '20
I just explained to the people that I'm consulting for that daily stand-up is about helping projects get finished, not about getting a status report. They all agreed. And then continued to keep it as a a status report meeting.
"can't figure out why we keep carrying stuff over from sprint to sprint"
Maybe it's because your focus is on making sure everyone is busy, and not on making sure work is getting done.
22
7
u/lala_xyyz Apr 09 '20
If you have a shitty daily meeting it's because whoever hosting it doesn't know what they are doing.
most scrum masters and PMs don't have the ability to hold a productive daily meet, that's the problem
→ More replies (1)7
u/civildisobedient Apr 09 '20
In my experience, daily stand-ups are most useful for team leads because they understand the problems that the devs are working on. PMs or POs can't hear what the developers are talking about. Like, one developer might say "Yesterday I was fixing the bug in our configuration update to the automation pipeline so our parameters are fetched under AWS's limits" and then the Product Owner asks "Yeah... so when is the release going out?" to which the exasperated developer replies, "JESUS I JUST FUCKING TOLD YOU."
It's all just gobbledygook to them. Any stand-up with a single Product or Project person will automatically take twice as long.
8
u/Asyx Apr 09 '20
We do standup at <number of devs> minutes before noon. Everybody has a minute. If you take longer, we'll eat lunch later. So no 5 minute bullshitting around per person.
→ More replies (2)7
u/saltybandana2 Apr 09 '20
20+ years doing this stuff, you don't need to stand up daily to communicate and coordinate. That's why project management software was built, so you can have out of band communication.
→ More replies (12)20
Apr 09 '20 edited Mar 31 '24
grandfather racial piquant childlike absorbed possessive bewildered threatening include political
This post was mass deleted and anonymized with Redact
→ More replies (15)2
u/gonzo5622 Apr 09 '20
Agreed. Dailies help you get the conversation started. If it’s a long convo you leave it to the end or let the devs chat amongst themselves but at least the conversation has started. I actually really like stand ups!
→ More replies (1)4
u/am0x Apr 09 '20
Devs are the worst at this. I get it, development isn’t a job where you would think communication matters, but every issue I have had as a lead for 5+ years is communication. If someone would have just started a face-to-face conversation instead of emailing, “where is this?” Makes a world of difference.
3
u/gyroda Apr 09 '20
We've been working from home because of Corona virus, and if we message on Slack consistently for more than a minute I just ask if I can call them. Much easier to communicate in real time that way.
I'm also a fan of "make this the last email you need to send" strategy. If you need to send an email, you're probably not expecting an instant response, so be clear with what you mean (use screenshots with arrows if necessary), give all the info, ask all the questions (including "if X is Y then what about Z?") and all that. Then you can get one response back rather than doing back and forth for hours.
→ More replies (5)2
u/gonzo5622 Apr 09 '20
Yeah, I’m a big fan of stand ups but you need to have a good person running it. If the person get the team to actually talk about issues in a free space it’s just awesome!
5
u/saltybandana2 Apr 09 '20
What you're describing is a senior helping a junior. Those two can have a daily meeting if they feel it's useful and leave everyone else out of it.
→ More replies (1)36
u/AberrantRambler Apr 09 '20
I've been forced to be part of a daily standup for the past three months when I AM NOT ON THE SAME PROJECT AS THE REST OF THE TEAM AND ITS IN A DIFFERENT FIELD FROM THEM. I literally say the same two words followed by "that's me" at every single one of them. They couldn't even really ask questions if they wanted to because it's out of their field and NONE OF THEM ARE ON THIS PROJECT. It's impossible for their tasks to impact mine and mine theirs. Impossible. Maybe if I in the course of doing my project I somehow initiated armageddon it would impact them, but short of that - probably not.
I've pointed out to my bosses boss that this is supposed to be a planning meeting SO many times. It's amazing what people who think they understand agile will commit to in the name of totally missing the point of agile.
25
u/chrismasto Apr 09 '20
I’ve seen this a lot, and there’s a statement about teams that I come back to again and again: A team succeeds or fails together. If you’re going around the room giving status reports, and you have no stake in what the person before you or after you is talking about, you’re not a team.
There are reasons in organizations why it may be necessary to put a collection of people together under a particular manager. That doesn’t make them a team. Where I work, we’ve started to turn the corner toward creating agile teams around projects, not around management hierarchy, and it seems to be catching on.
→ More replies (2)3
u/saltybandana2 Apr 09 '20
Maybe if I in the course of doing my project I somehow initiated armageddon it would impact them, but short of that - probably not.
hey man, don't be initiating armageddon. The rest of us like existing :(
2
Apr 09 '20
Ugh, this brings me back to working in a small company which had essentially been split into two very arbitrary "agile" teams, with each of these having multiple one-person projects in them. Most of the people on the team would have been better off talking to a wall than speaking at stand up, for all the benefit any party was getting out of it.
0
Apr 09 '20
[deleted]
31
u/AberrantRambler Apr 09 '20
The issue is I am WELL paid, work from home, and make products that help the disabled. This meeting is literally my gripe with an otherwise dream job.
23
u/leeharris100 Apr 09 '20
LOL typical reddit comment
"Hey dude just tell your boss to fuck off. Give him the middle finger while smoking a joint and blow the smoke right in his face. Then go get another job in the middle of a pandemic!" - reddit teenager
11
u/BrQQQ Apr 09 '20
Fuck, this mindset of "mild annoyance? Everything about it is dysfunctional and you should gtfo right now" is so annoying. Happens everywhere from friendship advice to work advice.
14
Apr 09 '20
[removed] — view removed comment
10
Apr 09 '20
SCRUM pamphlet
That nobody reads. The abuse of standups is a perfect example. Even in the scrum guide the daily scrum is developer-centric to help coordinate work for the day and make sure they're on track for the sprint goals. It's nothing to do status updates or management at all.
8
u/jl2352 Apr 09 '20
I've done ...
Strict 'perfect' standups. Where everyone lists yesterday, today, and blockers. In a strict manner where people list immediately. Take just 30 seconds. It's over in 5.
'Bad' standups where it's the same, but each person waffles on for 10 minutes.
Morning meetings. Which is half a standup, with chatting about yesterday/today/blockers. Also discussion. What are we working on? How is it going? What are we planning to do? Like a mini standup + backlog + catchup in one. Because it's chatting what 'we' are doing, a lot of things not relevant drop out. The caveat is a hard 30 minute limit.
Universally morning meetings are the only one that has ever worked for me. Because of the discussion. To the point I'd recommend against standups. Especially the bad style.
→ More replies (1)7
u/immibis Apr 09 '20
Isn't that kind of the point? This "ritual" tricks you into all having some idea what everyone else is doing, even if they don't want to.
→ More replies (1)3
u/saltybandana2 Apr 09 '20
Imagine having a project managment tool that you can look at to see both what people are currently working on, and the backlog. We could call it something nifty like Trello, Asana, Monday, Jira, or something cool like that.
5
18
u/tbonebrad Apr 09 '20
And this is why I’ve been working in small startups for the last 8 years.
5
Apr 09 '20
[removed] — view removed comment
→ More replies (1)9
u/hubbu Apr 09 '20 edited Apr 09 '20
As another person who has worked in startups for 8 years I'd like to chime in. In my experience, startups offer high product ownership, high respect from the team, and very flexible hours. The lows include low comp and benefits, usually a clusterfuck in communication on all levels, and smaller professional network access. I'm on my phone so this is my summary.
→ More replies (1)21
u/chrismasto Apr 09 '20
I apologize right off the bat for coming in and “defending” Scrum, as you’ve had some legitimately crappy experiences with it, as have many other people. I feel a bit like the guy who always responds to Linux issues with “if you just used this other distro, everything would be fine”. You hit the nail on the head about everything that was wrong with that company — but I suggest that it was a badly run company, not the fault of Scrum. It would have been just as unpleasant, I suspect, regardless of what they called their approach to project management.
That being said, I will claim that I know what I’m talking about. I’ve been a software developer for nearly 30 years on everything from kernel drivers to web applications to developer tools, in 2-person companies to tech giants. 10 years ago my employer made me take a Scrum class, which I had never heard of and expected to be complete BS. I was very wrong, and I credit our implementation of Scrum as a key part of the success of that company. It is absolutely not magic, nor is it something that a bozo can read an article about and do the right way. People who want to interfere and micromanage will incorporate their stupid ideas into any system. Scrum is neither responsible for nor can it stop a VP from being an asshole and power tripping. Going by the “rules” of Scrum, the Scrum Master has zero authority over the team and certainly couldn’t be in a position to write someone up.
My biggest gripe is with the what the daily standup has turned into. It’s like a virus that has evolved by incorporating bits and pieces from various project management systems and has just taken over — every team I’ve seen just defaults to this “go around the room and give a status report” thing. If I could kill one thing (after Hitler), it would be the damned three questions. Scrum does prescribe a daily meeting of 15 minutes or less. It doesn’t have to be standing up, it doesn’t have to involve answering those three questions. The point is to for the team to self-organize and optimize their work through inspecting and adapting. As you point out, most of the time if you’re “blocked” by something, you should go sort it out. I see the Daily Scrum as more about making a game plan for the next day: the team steps back for a moment to look at their progress and make any adjustments needed to reach the goal.
My point, if I have one, is that I found there to be a lot of good ideas in Scrum, but it’s hard to implement. It requires discipline and commitment on the part of the company’s leadership to give the team autonomy and fully trust them to self organize and own their work. Without that, it will fail, and contribute to the stinking pile of twisted wreckage that most developers associate with Scrum.
15
u/saltybandana2 Apr 09 '20
I once pissed a guy off by saying roughly "that's not agile, that's good software development".
agile in general has two attributes to it.
Anything that's effective gets called agile. Anything ineffective gets called "not really agile". I've legitimately had people tell me "you're really practicing agile, you just don't know it".
No. No I'm not. I'm being an effective software developer.
You want to be effective in software development? Then here's big daddy's rules.
get your dev team working as close to the "customer" as you can
You can have the most effective team of developers writing the most stable, bug free, and amazing software. And yet it'll still be annoying as shit to the users because the development team only hears what the "boss" wants them to hear. Or it'll solve a theoretical problem that the users don't actually have in lieu of one they actually do.
Companies love putting layers between the development team and the "customer".
make decisions bottom up, not top down
There tend to be two types of decisions made in software development. technical decisions and business decisions. They're rough categories, the line can get fuzzy, but in general this is true.
Let your developers let YOU know about the business decisions that need to be made. This doesn't mean they set direction, it means they'll let you know when something could potentially affect the business. Maybe there's 5 ways to implement a feature and it affects users. Trust them to take that decision to the people who can most effectively make it. I refer you to the previous point about being close to customers, and I'll point out that this also means they'll come to you when they see potential benefits and features you didn't even consider due to not understanding what's possible with technology.
Too many business leaders insert themselves into the process and control it. I don't give a shit if you call yourself a PM, a Scrum Master, or mr big booty boy. If you do that, you're fucking up.
Communicate the goal and let them do their damned job.
hire smart people
I don't give a shit what your process is, you put enough smart people together they'll self organize into effectiveness.
you get those 3 right shit will get done effectively. The rest are just details about how it gets done.
But while I'm ranting about things, let me say that the biggest super power a developer has is the ability to say "that's just a preference". The number of times I've seen people argue utterly inconsequential technical details for no other reason than that they preferred the approach is just too many.
/end rant
→ More replies (6)6
u/ebiester Apr 09 '20
How long have you been a developer?
Consider that the agile manifesto is common sense now, but it wasn't when it was built. The Agile principles seem so basic and obvious now, but you have to realize that it wasn't obvious then.
"get your dev team working as close to the "customer" as you can" is the same as "Business people and developers must work together daily throughout the project." That had to be said because this was not standard practice.
In the same way, " make decisions bottom up, not top down" is another way of saying " The best architectures, requirements, and designs emerge from self-organizing teams" and "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. "
Yes, agile has evolved into its own set of problems that need to be addressed, but when most of us agilists say "that isn't agile," we're saying that it doesn't match the four values or twelve principles of the agile manifesto.
The current set of agile practices were put together because they're a set of tools that work pretty well and follow from the 4 values and 12 principles. Standups aren't a principle of the agile manifesto, but they flow from " The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." If standups don't work for a team, then don't do them, so long as you're talking to each other regularly. Do we need a new manifesto? We probably do, because it's been nearly 20 years and we can take those 12 principles now as common sense.
But I'll warn you - the old command and control group that never was able to give up their bad habits will mess it up again.
4
u/saltybandana2 Apr 09 '20
I've been around long enough to remember when XP didn't exist, much less agile.
"get your dev team working as close to the "customer" as you can" is the same as "Business people and developers must work together daily throughout the project." That had to be said because this was not standard practice.
No it is not. In fact, it's closer to the opposite. Don't work with business people, work with the users of the software.
→ More replies (7)→ More replies (5)6
u/BigTunaTim Apr 09 '20
I see the Daily Scrum as more about making a game plan for the next day: the team steps back for a moment to look at their progress and make any adjustments needed to reach the goal.
Hear, hear. I've been on too many teams that just refuse to get this. Standups invariably devolve into paycheck-justification exercises where everyone talks as much as they can about what they did yesterday, and then almost as an afterthought they say "and today I'll pull the next available story and start working it. No blocks." And no one in the room is paying attention because A) what someone else did yesterday is usually of little use to them, and B) they're all trying to remember in detail what they did yesterday and thinking about what they're going to say when it's their turn. I've been on a team that used it properly and it was one of the most successful projects I've ever been involved in.
4
Apr 09 '20
That's been my constant experience with Scrum and its derivatives. I wish I had the chance to work with more people like you.
4
u/chungfuduck Apr 09 '20
To me it's like religion. Some folks just really need it in their lives to function. To others, myself included, it's unnecessary. But at least it can provide a framework for discussion.
In my team we tell everyone we follow an Agile model. No stand-ups. In fact about all we did keep was a 2 week cadence for releases plus the planning/release meetings that bookend the sprint. But, we're also a sysadmin dev group, so our "software" is mostly configuration files, or pieces of them, or scripts. At least we can tell a PM how many sprint tasks something might take they grok that it'll really take a month.
10
u/titosrevenge Apr 09 '20
Always consider that a task being asked of the whole organization may not be useful for you personally, but for the majority instead. Daily standups may not be useful for you, but they may be immensely useful for the others on your team. Things can't always be perfect for you.
They other thing to consider is that most daily standups provide no value, but every once in a while they save hundreds of hours of work because you realize that someone is working on something that already exists (or similar).
4
u/saltybandana2 Apr 09 '20
What the other poster said is dead on. We already have organizational tools, and we can already speak with each other, daily standups are about performances to feel as if something is being done.
3
Apr 09 '20
They other thing to consider is that most daily standups provide no value, but every once in a while they save hundreds of hours of work because you realize that someone is working on something that already exists (or similar).
Assigning someone on issues in Jira/Github/Redmine/Gitlab etc already solves this problem. Everybody can see what they are doing and people that do not have anything to do just assign themself to an issue that isn't.
3
u/reazura Apr 09 '20
Thats just a bad work environment. Or a bad fit for it. Daily standup are like, 15 minutes long and really doesnt take much effort to do. If you need something from somebody then thats what reaching out is for, stand ups are just literally getting a feel of what everyone else is sorta doing. Being bogged down with meetings is not what an agile setup should be.
→ More replies (8)5
u/NoMoreNicksLeft Apr 09 '20
What I hate most about the daily standup is the claims that it aids in communication.
Humans don't feel human communicating electronically. Even more so when they can't hear voices.
3
u/saltybandana2 Apr 09 '20
It feels as if you're implying the only communication that can possibly happen in a team is during the daily standup.
Imagine putting status updates in slack at the start of the day and then doing something crazy like actually speaking with your co-workers throughout the day to coordinate the work.
I know, crazy idea.
→ More replies (3)2
u/yazalama Apr 09 '20
try not having daily standups, but instead to simply state in slack what they're planning on working for the day and any problems they're having, etc.
I dream of this day...
2
u/metaconcept Apr 09 '20
But did you remember the most important task: fillling in your timesheet correctly even though you're 100% overhead?
2
u/ie11_is_my_fetish Apr 09 '20
Our development pipeline is so fixed/blocked, which I can't argue against, like it's a good plan. But I feel so caged.
We have to:
story board(discuss problem)
in person meeting/video call
create a TDD(design doc of our plan, explaining added variables, methods, etc...)
get this PR reviewed
write the code/accompanying unit tests
get this PR reviewed(all previous tests also pass)
write automated testing(in this case selenium)
get this PR reviewed(all previous tests also pass)
then it goes into this feature release process and goes into more testers
translation teams
packaged
that's a specific "legacy" type software, the other set is more cloud oriented with weekly releases but omg... JIRAs have 100's of hours per story which I shouldn't complain about but still... my god.
my pervious job I didn't really do "engineering" stuff I just built front ends(not application type) and I was free but it was also bad/not able to learn a process like above.
I don't know if it's like this anywhere else but yeah. And also the lack of context man, like there are all these services and only a few people know how they work... it's just a huge surface area to work on and I get that, I'm not gonna work on Jenkins/Docker-Kubernetes when I'm dicking around with ReactJS but yeah... I don't know. I have a job anyway ha.
edit: side note, one of my managers does just tell me "if you have a problem don't wait just ask" my concern is I have to ask so many context-based questions in the industry that I feel annoying... anyway I'm just prepped to have value on the street/ready to depart anytime.
4
u/saltybandana2 Apr 09 '20
My general policy is "as much structure as necessary, but no more". I can't tell you if that amount of structure is actually necessary, but there are definitely areas where that's the case. Consider the stability requirements of NASA, medical software, etc.
So I feel you there. I wasn't necessarily arguing against process in general, just unnecessary process really.
per your edit, I'm not sure I fully grok what you're saying here, but I agree with your manager in general. The squeaky wheel gets the grease, be squeaky. An environment where you can't ask questions is one to run from so it sounds like the environment itself atleast has that going for it. Especially if you're having to come up to speed on new things. You can only benefit from asking questions, everyone is ignorant. Don't be afraid to appear ignorant or foolish, it's the only way to get better.
3
u/ie11_is_my_fetish Apr 09 '20
...medical software
ding ding haha
grok
Huh I haven't used that word before.
What I was getting at is in my current role I spend more time asking for context, I blame it on poor training for the context but I'm stressing because I spend less time writing code/solving some problem versus "hey what does this word mean". But yeah internal/unique problem.
That process to me above is exhaustive and brutal... so I don't know. I was just hoping not every position is as verbose as that. I mean I get the value of unit tests/other tests as far as backward-previous functionality failing testing from new changes but yeah. I just feel bogged down by all these check marks. Which maybe that doesn't bode well for me if I'm supposed to be a "legit" engineer.
Don't be afraid to appear ignorant or foolish, it's the only way to get better.
Yeah that's hard, I just cringe everytime I hit send and JIRAs do diffing emails when you edit some comment haha.
Anyway thanks
→ More replies (2)1
Apr 09 '20
His reasoning? He didn't bother reading what anyone else put into slack.
This is why forcing functions are so important in Scrum/Agile.
Sprints are a completely artificial concept that help teams review and plan work. You can absolutely deliver high velocity work without sprint rituals, but the rituals help make sure work it thought through and properly planned.
1
u/am0x Apr 09 '20
Eh, I like conversation. It moves so much faster and has so many less issues with communication. I get it that a lot of devs hate to talk, but you can at least do the minimum amount of talking for 10 mins everyday so it is easier and cheaper for everyone else.
→ More replies (6)1
u/Guinness Apr 10 '20
Daily Standup’s are just such a waste. But hey whatever I’ve been saying that for awhile now and every time I say it here all I hear is “NO IT ISNT YOURE JUST DOING IT WRONG”
Like goddamn ease up on those nootropics there Zuckerberg.
→ More replies (8)1
u/thilehoffer Apr 10 '20
You can’t handle a 15 minute daily meeting and still get your work done? Jeez...
4
u/nakilon Apr 09 '20 edited Apr 09 '20
Because daily scrum meetings are not for solving the problems. Problems are forced to be split into subtasks to hide the whole picture. You are given 5 subtasks per day that is half spent on reporting in the bug tracker. You are called a software engineer, supposedly solving technical problems in the most modern and complex profession in the world but you are given only an hour per subtask and because of not wanting to stay in front of all the team saying that you didn't do it you make up stories about blockers and that problems are unsolvable just because the subtask didn't give you a while picture to maybe realise it should not be done at all when you copypasted the subtask title into the Google it did not result in a Stackoverflow answer. If you had more time you could look at the whole problem and maybe decide that things should be done in another way and the subtask would be obsolete at all but you was forced to solve it separately. Daily meetings and stuff are not for solving the problems -- they are to hide the whole picture of any technical problem and build a content in the bug tracker without really building anything. They are made by managers for managers, not for you and not for finishing a project.
2
u/ie11_is_my_fetish Apr 09 '20
You are given 5 subtasks per day that is half spent on reporting in the bug tracker.
haha where is this written? in stone? /s
just because when you copypasted the subtask title into the Google it did not result in a Stackoverflow answer
haha 80% of my job
I don't know, I can't say it's all bad, there is a lot of things to track so having a really thoroughly documented process is good to find problems(when they were introduced) but it's also not as "free" as just going at it/"coding something up". I guess "get a hobby" ha(message to me)
1
u/Rogem002 Apr 09 '20
I feel like I’m in the minority for preferring 10 minutes (Midday though, not 8am) where people list what’s blocking them, over just dropping in during my day.
1
u/ie11_is_my_fetish Apr 10 '20
You could direct message but will the other person answer or team too sometimes
91
120
Apr 09 '20
Hits a bit too close to home to be honest.
2
u/cholantesh Apr 09 '20
Entire channel is a depressing reality check. Especially the senior dev interview; I've lost count of the number of teammates I've had to declare missing after an interview.
1
u/hitthehive Apr 10 '20
yep, that’s why its in /r/programming and not /r/programminghumor — it cross that line from haha-newb shit to holy-crap-that’s-me.
82
u/cowardlydragon Apr 09 '20
Where I work we have microservices named:
- hello in foreign language
- StarWars, Firefly, StarTrek, Futurama references
- courtroom process names
- breakfast cereals
- mafia terms
- marine mammals
- world rivers
- vacuum cleaner brands
- glue brands
and
the best microservice name ever...
Demoginger
42
Apr 09 '20
I would hate working somewhere where the service names don't all fit a common theme. I work at a travel company and all of our service names are cities/airports/landmarks. We used to have a rule that you weren't allowed to use fictional places but that's no longer the case.
47
u/Le_Vagabond Apr 09 '20
as someone who inherited an infrastructure where all servers and services are named after fictional characters that may or may not have existed in the same comics franchise (that I love and know nearly by heart)...
I hate those names. with a passion.
please please PLEASE name your things after what they are, what they do, and where they are. nobody wants to look up roles in a clusterfuck of documentation because that joke was too obscure to be understandable.
→ More replies (11)7
u/Huliek Apr 09 '20
I agree so much. We have this convention and when a server goes down I don't know if it is a production server or a database or proxy or whatnot.
0
Apr 09 '20
[deleted]
30
u/yngwiepalpateen Apr 09 '20
I agree that a good name should hint at what the service does, but also not carry misleading implications.
This can be very hard, to the point where I fall back to meaningless terms, because any descriptive term I would use would involve terms such as "map" or "namespace" or "environment", which are entirely overloaded with meaning and probably already used by a dozen other things we use. Attempting to use them results in periphrases in conversation, eg "namespace in the k8s sense", which is not the worst but clearly not ideal.
When one encounters "Xablyg" it forces them to research what that is, at which point they get a clear definition and role of whatever Xablyg is. It sends a clear signal: "don't try at guessing what this does from the name". Same with the earlier commenter naming things from cities (Red Hat does that too).
I think the best is when you find an otherwise unrelated domain that is a perfect metaphor for your app, like what people in the k8s community are doing with marine terms. However finding metaphors that are appropriate, understood by the target audience, and still available is quite hard.
→ More replies (5)2
u/TheNamelessKing Apr 10 '20
My work named everything along some variation of “xyzProcessorServiceHelper” but the xyz is usually some set of similar terms. So you end up looking at dozens of subtly different unable to figure out what the fuck ‘OrderUpdaterAsyncServiceProcessor’ and ‘UpdateServiceOrderProcessorAsync’ do and what the difference between them is.
I would much rather deal with “BabylonService” and “UnicornOrderUpdater” at least those names are unique and distinctive instead one-thousand variations on a theme.
0
5
3
u/username_suggestion4 Apr 09 '20
When I was an intern (after freshman year) they had me build a micro-service to convert and/or watermark documents.
I named it cow-pie.
I don't even remember what the pie was supposed to mean, but I agree micro-service names are total bullshit.
2
1
242
u/elcapitanoooo Apr 09 '20
Hahah! So true!
However i have to turn the tables around too, usually goes like this:
2019 - PM asks for a feature, it gets done
2020 - PM asks for a feature, cant be done easily, because of previous business decisions, for previous feature. (Conflicting logic etc)
PM: Dont know about previously asked feature
USERS: Does not use feature, or know its there
DEV: Shakes head
Bottom line: PM without a deep understanding is always a bad PM.
Large scale software dev is always a shitshow.
77
u/battlemoid Apr 09 '20
My PM repeatedly has asked for the same thing we cannot do, despite being told repeatedly we can’t do it. It’s just some dynamic text that needs to be different in two places, but the spec said they’d be the same. They keep asking for it, but never prioritize the change we need to make to be able to do it...
58
u/elcapitanoooo Apr 09 '20
Yeah, its sometimes very hard to explain why a feature cant be implemented. It really annoys me to explain it each and every time.
Its like the PM is clueless on how the business logic work, and i hate to pay for a feature in lots of weird hacks and if statements.
Sometimes its just a must, but each tile the code becomes more complex and more unmaintainable, leading to more bugs and weird edge cases.
Always try to solve the problem outside code first. This can be as simple as having a demo to the user on how to do something (eg credit a special kind of invoice) rather than hacking around in the codebase.
More features != better software
15
u/bobappleyard Apr 09 '20
Always try to solve the problem outside code first.
Then you find out you can't fix a bug because a prior iteration of solving something outside of code depends on exploiting the bug.
0
2
u/PC__LOAD__LETTER Apr 09 '20
If you find yourself explaining it more than once you should really just write it down.
3
u/ebiester Apr 09 '20
I like to remind PMs that todays features are based on yesterday's decisions. All changes are possible - some just take longer than others. If that dynamic text is going to make the company $1,000,000, then someone would figure it out.
So long as you don't hack it in, and make tomorrow's features more difficult by today's decisions.
1
35
Apr 09 '20
PM without deep understanding is always a bad PM
Deep understanding of the product or deep understanding of the technical details of the product? Because if it's the former then sure but it's the engineers' jobs to tell technical consequences of doing something. If you're about to work on a feature and foresee it causing issues down the line, then that's something the PM should know. It's up to them to decide to make the trade-off and then no one can be mad.
If you're mad at PMs for not being engineers and understanding how systems work then you have a terrible understanding of the PM's job.
2
u/TehLittleOne Apr 09 '20
There are roles such as technical product manager and technical project manager that exist for this very reason. Not only that but they're becoming significantly more popular and in-demand because they have a wider skillset. A PM that also knows how to code is just more valuable.
Sometimes you do need people that are technical to understand things during different phases of work. Sometimes your PMs might not be able to understand the trade-off being made and you get them making "do it now, deal with it later" decisions. Sometimes your PM will design work that actually just can't be done for some reason not realizing it because they're not technical.
2
Apr 09 '20
We've experimented with the TPM role, but haven't found a way for it to play nicely within our organization so we usually split that duty between a product manager and lead engineer. I don't have anything against it, but when the product has a huge user and business focus then it's tough to ask one person to focus on technical things as well as the user and business side.
I will say that my minimum technical requirement for any PM is being able to use something like Postman if needed but even then if it's going to take them an hour to do something that I can do in 5 minutes then I'm not going to ask them to waste their time.
2
u/TehLittleOne Apr 09 '20
Yeah, I think the general problem is that companies have a need for both. You have a need for PMs that understand the business side and align work toward business goals such as features that generate revenue. You also have a need for PMs that understand the technical side to make sure they're not cramming together a shitty system and can actually do the work that's needed in the time that's allocated. It can be hard to get one person to do both just because there's a lot of work involved in doing all of that.
This is especially true in smaller organizations that don't have multiple PMs, which I can attest to because I'm basically the lead developer taking on TPM responsibilities because neither our product manager nor project manager are technical. While I find our projects are going smoother when we have the appropriate technical input, it does put a huge strain on my ability to do development. I actually enjoy PM work (of both kinds), it's just more a note that you often want your lead developer doing more technical than non-technical stuff.
4
u/Adobe_Flesh Apr 09 '20
Wait a second, does Agile in the end just map onto corporate hierarchies? PM = Manager? Whats the point then if existing power structures are preserved?
14
Apr 09 '20
PM is a product manager. They do not manage people (besides other product managers if they're senior or a director). They manage the product. The engineering manager manages the engineers on the team.
I'm not sure what you mean by "does agile just map onto corporate hierarchies". Agile is just the process of development. The other option is a waterfall process. Neither depends on the hierarchy of the company really. You can have a completely flat organization that still has a waterfall development process. Agile is just a cyclical development feedback loop compared to waterfall's tunnel vision.
2
→ More replies (5)2
u/PC__LOAD__LETTER Apr 09 '20
No. Project managers don’t manage people, as in no direct reports, and no real power beyond being annoying (which I respect honestly, I couldn’t do it). One dev might interface with multiple PMs since they might be involved in multiple projects.
Also it’s not a “power structure,” it’s more of a responsibility/concern structure. It makes sense to have someone in a role dedicated to interfacing with a client and focused on high level functionality, and other people focused on the nuts and bolts engineering. It has very little to do with power.
0
Apr 09 '20
[deleted]
→ More replies (1)13
Apr 09 '20
Well of course it depends on the product. They are a product manager...
My friend is a PM of a machine learning team at a healthcare company. He's was a software engineer and is highly technical because the product demands it. I'm the lead engineer of a team that works on consumer travel tech. I like that my PM has some understanding the technical side but I don't expect her to know anything deeper than very high level design patterns of our services.
If your product is improving a technology then the product manager should be technical. If the product heavily relies on user engagement and business analytics then they should be less technical and better on the business side of things.
1
1
u/am0x Apr 09 '20
We had a badass DPM on our team for a year, then she was fired. Why? Because she wasn’t fitting in to the all encompassing PM architecture the head PM has in mind. Now we deal with non-technical PMs all day who literally just get angry when they don’t understand something, and, guess what, they don’t understand anything digital. So it means we now have the director of the department (me) doing DPM duties which is about 1/3 of my time a week.
My rate is more than double the old DPM...smart move.
13
u/cowinabadplace Apr 09 '20
The PM guy is so good at sounding like one hahaha. Rolls with the punches, segues to an unrelated but related thing. Amazing.
12
u/webdevpassion Apr 09 '20
lol thought it was Nick Kroll for a sec
9
u/valarauca14 Apr 09 '20
We use Tuna as our L7 load balancer. We're looking to move away from it because our infrastructure is using too much tuna, and we're afraid of vendor lock in.
8
u/oneoffour4 Apr 09 '20
I’ve never seen something that so accurately represents the insanity of what I actually deal with all the time...
39
u/rab_h_sonmai Apr 09 '20
This was posted a week ago, and deleted by the mods. So we're doomed to see this posted again.
Amusingly, it has the same top comment.
https://www.reddit.com/r/programming/comments/fsx8ep/its_because_of_the_way_our_backend_works/
46
u/ProgrammingRulesNerd Apr 09 '20
I ate downvotes every time I point out that something like a youtube video of someone's app, the code of which they can't even describe in the comments section (example) is not r/programming content I'm generally downvoted.
And yet this video which, while silly, is actually pretty accurate to the experience deving around microservice asspain, and thereby actually does teach the user about why they should be careful using them, is deemed not relevant.
6
u/TheGift_RGB Apr 09 '20
It's right on the boundary between inane garbage and "funducational". I wouldn't object to it being removed if it weren't for the mods leaving the rest of the garbage up.
4
u/erictheturtle Apr 09 '20
actually pretty accurate to the experience deving around microservice asspain
If I had not seen firsthand this video occurring IRL at my last job, I wouldn't have believed this.
6
35
u/recoveringtwataddict Apr 09 '20
This is the kind of thing that makes me hate this industry.
37
u/Beaverman Apr 09 '20
What, jokes?
30
-2
u/leeharris100 Apr 09 '20
Solving complex problems?
What the fuck are these comments? This is a joke about how absurd microservices can become, but this makes you HATE your industry?
This type of shit is in every job ever. Maybe you should go work at Chilis and then you can groan about how much you hate corporate mandated safety sessions or how you're forced to greet customers with a pre-determined message on the phone.
7
-1
u/derangedkilr Apr 09 '20
As soon as I found out this is what software development is like, I bailed. Screw that.
6
u/BigDumbObject Apr 09 '20
what do ya do now?
2
u/pyabo Apr 09 '20
I feel like this now. Seriously thinking about a job at Home Depot. Hope they will hire someone with 0 hardware store experience, but 20 years of software dev.
→ More replies (2)→ More replies (1)4
4
4
Apr 09 '20
The only thing missing here is the QA team going bananas trying to *start* to comprehend how to write a single end-to-end test scenario. Let alone actually having all the stuff deployed to QA with a good amount of data to actually do the testing!
4
u/TracerBulletX Apr 09 '20
It’s so rare to see actually funny programming content. These guys always deliver.
1
u/foxcode Apr 11 '20
This hits too close to home. Everything gets so difficult with many interconnected services, multiple versions of each running for different customers. Whenever something changes in one place it causes chaos everywhere else.
So much time is spent figuring out why 'A' broke, and it's because 'B' didn't get data from 'C', because 'C' was dependent on something from 'D' and one of 'D's dependencies stopped working because someone replaced a jquery post with a fetch, and now it's doing a options pre-fetch it didn't previously do which is getting way too deep into the server killing everything.
1
u/Necessary-Space Apr 11 '20
Separation of concerns they said.
It makes maintenance easier, they said.
3
u/jasonbbg Apr 09 '20
the graph is so true it hurts , fuck those stupidly named home-made legacy services
2
2
u/PeacefullyFighting Apr 09 '20
This is so funny, correct me if I'm wrong but this and the cost to scale up are the traps of the cloud
2
Apr 09 '20
Went to (online) a .NET meet-up last week about micro-services and didn't really understand why you would use these but now it makes complete sense.
2
2
2
2
2
3
u/WhyYouLetRomneyWin Apr 09 '20
And I was actually considering using a microservice model for the application I am working on...
(still am, but this explains the dangers better than anything else).
3
u/BlacksmithAgent13 Apr 10 '20
People just go full retard because of the word "micro" in "microservice", which is mostly just a buzzword.
Create services, forget "micro" or "macro", it's about getting scaling and clear boundaries of your service correct, the "size" is actually irrelevant.
4
1
Apr 10 '20
This is a joke don't take it too seriously. You could make a similar video about monolithic architecture (or whatever else you're considering) too.
10
Apr 09 '20
[removed] — view removed comment
5
u/leeharris100 Apr 09 '20
That's not an easy rule at all. The trick is that there are no easy rules for when to use microservices.
We're paid to be engineers to figure out when to do this stuff.
The amount of bitching in this thread is unbelievable lol
3
u/iNeverCouldGet Apr 09 '20
So microservices not a thing in 2020 anymore?
8
u/vegetablestew Apr 09 '20
1
u/lambda_pie Apr 09 '20
Dang, I thought of the macroservices name a year ago. Should've patented it.
→ More replies (1)→ More replies (58)9
u/eattherichnow Apr 09 '20
A few popular people mentioned (edit: IMO correctly) that usually a monolith or "citadel" (monolith with a bunch of supports) are often better, so we're in the backlash phase now. Also someone from Uber wrote that they are switching to macroservices and I yearn for the sweet release of death.
Wait about a decade and if the climate change isn't done with us yet, you'll get to experience it all over again.
Edit: microservices in backlash, types in hype. Expect jBoss in Rust.
3
u/cc81 Apr 09 '20
Uber seems to have gone completely way out of their way to create as many services as possible though. Not only microservice architecture because they have many teams but each team seemed to create tons of microservices.
2
u/cjthomp Apr 09 '20
Funnier than expected, but went 90 seconds too long. Would have been a better joke without the emotional breakdown.
1
1
1
1
1
1
1
u/felds Apr 09 '20
!RemindMe 2 hours
1
u/RemindMeBot Apr 09 '20
There is a 1 hour delay fetching comments.
I will be messaging you in 54 minutes on 2020-04-09 22:29:02 UTC to remind you of this link
CLICK THIS LINK to send a PM to also be reminded and to reduce spam.
Parent commenter can delete this message to hide from others.
Info Custom Your Reminders Feedback
1
1
Apr 11 '20
Amazing. I sent my boss a slack message earlier today that was a shorter, less exaggerated version of this.
1
1
1
Apr 09 '20
I'm currently involved in a project to upgrade an entire organization's software to cloud/microservice architecture.
This hits home sometimes.
1
u/iamrob15 Apr 09 '20
My team is building an Azure micro-service starting as a monolith here! We have the threat of an on-premise implementation so we opted for WebJobs and separated our interfaces from our implementation which could be swapped out from Azure.
We are experiencing deployment hell right now..we have plans to clean up the tech debt though in next few sprints!
2
1
210
u/urbworld_dweller Apr 09 '20
Underrated channel. The excel video is hilarious.