Ready for launch
-
I just had a lunch with my brother. He is a senior react developer / team lead at a different company.
He was telling me about his upcoming big product launch after 6-9 months of development.
Brother: We are in a good shape. Last few features are out the door. We are now setting up a limited demo, fix the last few bugs, some QA, then next week, the release.
Me: Sounds good. Must be nice to work in a well organized company, not in a chaotic startup like mine.
Then I started whining about my interviews and how I can't seem to find a good candidate.
Me: ... What I really want, but can't seem to find, is someone with the attention to details. The coworkers I always end up saddled with are all about taking the shortest route to the goal.
Me: .... Rush rush rush, the moment the feature seems operable, they are done. No testing, no exception handling, no polish at all.
Me: ... In the code I am trying to merge now, all error handlers are just
console.log-s. The moment you go off the beaten path, the thing crashes and just hangs there, looking like an incomplete mess. It's atrocious.At some point during my bitch fest, I realize my brother's got kind of a "deer in the headlights" look on his face.
Brother: Umm... I just realized... we still don't have any error handling.
Me: What do you mean?
Brother: It's all TODO-s and
console.log-s.Me: ....
Brother: The initial design didn't include any kind of notification UI. So we just left placeholders all over the place and postponed doing error handling until the design is ready.
Me: ....
Brother: Management and UX guys are in charge of the feature list and what's gonna be done in each sprint. They were just adding one new feature after another. Error handling kept getting pushed back.
Me: ....
Brother: And then... I guess we just kind of... forgot.
Me: ....
Brother: ....
Me: .... Waiter! Check please.
Brother: I guess I'll go clear my schedule, huh.
Me: And I'll go and post this on WTDWTF.
-
That reminds me; I need to audit our codebase to check for infinite loops.
-
10 WRITE CODE 20 AUDIT CODE FOR INFINITE LOOPS 30 GOTO 10
-
@cartman82 said in Ready for launch:
Management and UX guys are in charge of the feature list and what's gonna be done in each sprint. They were just adding one new feature after another. Error handling kept getting pushed back.
It's interesting how often management messes this kind of stuff up, considering it's literally their entire job to stop this from happening.
-
@anonymous234 said in Ready for launch:
It's interesting how often management messes this kind of stuff up, considering it's literally their entire job to stop this from happening.
The cynical part of me says their job is to satisfy their higher-ups who only focus on the stuff they can see. If you spend time error handling and doing stuff that makes everything behind the scenes work robustly, they don't see that, and complain that you "haven't done anything" in those hours. If your managers lack a spine, they'll just repeat what they heard from the execs, and say "forget all the invisible stuff!"
-
@the_quiet_one said in Ready for launch:
their job is to satisfy their higher-ups who only focus on the stuff they can see
That's a good point.
But it only passes the buck to the higher ups. Their entire job is to think rationally and avoid doing this kind of stuff.
And then again, capitalism's job is to make companies with bad executives go bankrupt...
-
@the_quiet_one
Though if you're doing error handling and making things work robustly in a way that doesn't provide feedback to the business on what the value in your work was, then you have room to improve what work you're doing.For example, my current kick at work is SQL performance tuning. Totally "doing nothing" type work, now that we're past the initial "everything is broken" stage of post-migration. So I need to be able to provide a measurable to my manager to justify my continued time... "Hey, I saved this many cores worth of CPU time with these changes, we'll be able to pull back 4 of the cores we added post-migration and not have to spend that money when our next True Up comes around." "Hey, I reduced potential IOPS on the shared SAN by X, which also reduces memory pressure on the SQL server so we won't have to evaluate putting more memory in the underlying hosts, saving $Y."
Yeah, it kind of sucks to have to step out of the world of pure technical and think about things from a business perspective. But stepping back and determining the business justification for your work also helps prevent YAGNI problems from wasting a bunch of your current time and a bunch of future you's time fixing the messes caused by premature optimization.
-
@anonymous234 said in Ready for launch:
But it only passes the buck to the higher ups. Their entire job is to think rationally and avoid doing this kind of stuff.
Yes, but unfortunately it's their own bosses who say what their job is. It's true that's supposed to be what their job is, but according to their work detail as specified by the execs, their job is the same as everyone else's at a company like that: "Do as I say."
@izzion Yes, that's true. But with some crap employers, good luck even getting to the point where you can convince them to give you the opportunity to do that work to provide said metrics.
-
@izzion said in Ready for launch:
Yeah, it kind of sucks to have to step out of the world of pure technical and think about things from a business perspective.
Whether or not it sucks (it doesn't), it's part of your job. You're working for a business, so you should think about what the business needs, and how to express that in terms the business people can appreciate, that is, in terms of money gained or not spent, and money spent or not gained, and time spent gaining or not gaining or spending or not spending that money.
Yes, you have to be good at the technical stuff, but if you can't talk in terms of business, you will find your interactions with the business types to be frustrating and unproductive, and they will find the same thing. If you can, it will all run better. AND it will help you get them to understand things from your point of view. And that, too, will help things run better.
-
@izzion said in Ready for launch:
10 WRITE CODE 20 AUDIT CODE FOR INFINITE LOOPS 30 GOTO 10In the spirit of the topic it should actually be
10 WRITE CODE 20 GOTO 10 30 AUDIT CODE FOR INFINITE LOOPS
-
@the_quiet_one said in Ready for launch:
It's true that's supposed to be what their job is, but according to their work detail as specified by the execs, their job is the same as everyone else's at a company like that: "Do as I say."
Hence why we have a system where the people who benefit most from a company's success (the owners) are the ones who are in control of it. So that the buck stops there and they have a personal incentive to do things right.
-
Whereas here, people spent so much effort on logging and notifications that it takes a week to add a new email to the system, and no one is willing to look at logs with so much extraneous information.
Everyone was so focused on bloating the software, our prospective customers are still saying we don't really have the features for them to consider us seriously yet. And we release this week.
-
@magus said in Ready for launch:
Whereas here, people spent so much effort on logging and notifications that it takes a week to add a new email to the system, and no one is willing to look at logs with so much extraneous information.
Everyone was so focused on bloating the software, our prospective customers are still saying we don't really have the features for them to consider us seriously yet. And we release this week.I can't imagine a company that is solely focused on polish and robustness, instead of the endless feature churn, which is my experience.
-
@cartman82 They spent months on future proofing something that I sincerely hope we never allow customers to use the way they wanted to prepare for, and that if we do give them the ability to customize to that extent, it won't be until next year.
Half our product people left around the same time, because they all just happened to find new opportunities at places where features presumably get done, rather than being buggy and incomplete after 4 months.
We have so much technical debt after just a year of work, it takes longer to get anything done than in our thirty-year-old legacy application.
And did I mention that it takes a minimum of five seconds to load our initial login page on our glorious new now publicly available website...? From our office, with a good connection?
Yeah.
And best of all, they bought us all shirts to celebrate a successful release.
-
@anonymous234 said in Ready for launch:
capitalism's job is to make companies with bad executives go bankrupt...
It seems to be working white well!
-
@magus Similar thing happened in a past employer, where we went from extreme future proofing and back-end architecting to extreme "only work on stuff I can see" stuff. Basic story was this:
We had a CTO who was extremely picky about aspects of the codebase, where we spent so much of our time with micro-optimizations and bikeshedding the interior code that, after 6 months of work, we had nothing to show for it (and, I mean nothing... not even a mocked page). CEO got all pissy and demanded we produce something that he can see. At that point, he took over the managing part, told the CTO what the priorities were, hence why we were in the opposite position where internal stuff that did need to be done was sent to the backburner, and the CEO was way too picky about the look and feel of the UI, kept making stupid tweaks that lead to a half-baked app that was full of bugs and performed terribly.
In effect, we went from one stupid extreme to another, and eventually it caught up to us, which lead to the reason why they're a past employer.
-
@the_quiet_one said in Ready for launch:
and the CEO was way too picky about the look and feel of the UI, kept making stupid tweaks that lead to a half-baked app
I sympathise, deeply. Mostly from resembling the remark.
