|
Boiled Water posted:Its like an intensive course in everything at the same time Truth. I worked in a tiny startup (5 people) and got the hell out because... I was the only one who put out fires. Our CTO (my boss) was obsessed with shiny tech and 100% of his time would be spent essentially playing with toys while every crash, every client request, every new application feature, even a lot of design, would be completely on me. Across 3 different platforms. :sob: I now work at another startup, but a much more reasonably sized one (30ish people). There's still a similar element of "agility" where you're expected to move fast and keep new developments coming. But because there's a decent size the workload is distributed better and there is some room for specialization and I'm not the one who every disaster falls to. I think I want my next job to not be at a startup, but this is a workable middle-ground for me.
|
#
?
Jul 5, 2018 17:29
|
|
|
|
| # ? May 17, 2024 23:41 |
|
|
quote:edit: everyone in my office is gone now
|
|
#
?
Jul 5, 2018 18:02
|
|
I think my boss took them somewhere? His car is gone, they are all gone. Curious but I guess whatever?
|
Shirec posted:As a random aside, I think I'm going to go through my posts here and in the Newbie thread, save them and flesh them out a bit more coherently, and save it for later use. I know I personally want to help encourage other women/minority devs in the industry, and speak at conferences in that vein, and maybe those experiences will be useful later. Or maybe not? I'm not sure but at least I can do some groundwork now I have some loose diary-esque .txt files I saved from my worst job. I would scribble down whatever it was that was driving me crazy in the moment and then revisit them anytime I had second thoughts about job hunting. I don't think I would ever make them public, but it was nice to have contemporaneous notes to reassure me that yes, things were that bad, and no, I wasn't wrong to leave.
|
|
#
?
Jul 5, 2018 18:18
|
|
|
Shirec posted:edit: everyone in my office is gone now Like the Pharaohs of yore, he's going to lay down into his grave and bring them with him, so that they can do his reporting in the afterlife as well.
|
|
#
?
Jul 5, 2018 18:54
|
|
|
Volmarias posted:Like the Pharaohs of yore, he's going to lay down into his grave and bring them with him, so that they can do his reporting in the afterlife as well. I figured he was going to lure them all somewhere and try to frame Shirec for the murders, but we can hope for this outcome instead.
|
|
#
?
Jul 5, 2018 19:19
|
|
|
I wish I could say I did something useful today but instead I took a controller and a repository and made it into a controller -> service -> repository model with a querybuilder on the side. Upside: every part is testable by itself. Downside: no business value. The PO is complaining about the lack of business value and how, when the project started two years back with two devs things were so much faster than now with 6 devs. Explaining to him we are no paying off the debt he took on then AND that we have to ensure past functionality remains working for which we have to write a lot of tests because guess what, nobody did back then... seems pointless. I guess project abandonment and skeletal maintenance is in the near future.
|
|
#
?
Jul 5, 2018 19:31
|
|
|
more startup.txt: The B2B sales manager asked for help to calculate the numbers needed for his bonus. Turns out these never enter into any database, or really anywhere but are input by hand to a spreadsheet then sent off to a billings company. This in turn means no one knows who is billed what exactly and nothing can be verified. Back when the startup startupped it was constructed by the CTO, who by his own admission is a "fast gun" and does things "six shooter style" (not sure how well this translates). I've taken this to mean: Everything this man touches turns into a mountain of tech debt.
|
|
#
?
Jul 5, 2018 20:17
|
|
|
Keetron posted:I wish I could say I did something useful today but instead I took a controller and a repository and made it into a controller -> service -> repository model with a querybuilder on the side. Upside: every part is testable by itself. Downside: no business value. Tech debt removal and testibility and good architecture have very high business value, it's just indirect instead of direct. If your PO doesn't understand that they're an idiot and shouldn't be a PO.
|
|
#
?
Jul 5, 2018 20:23
|
|
|
Shirec posted:
Just go home for the rest of the day imo
|
|
#
?
Jul 5, 2018 20:23
|
|
|
I'm an independent consultant, and I've been with my current client for a couple years now. It's actually a pretty good gig, but I feel like it's time to move on to a new project, so I've been putting the feelers out for new clients. I managed to get a lead on a gig, and it seemed to be a good fit. They even were doing similar stuff to a client I had back in 2013, so it seemed like a natural fit. They're a startup (this shouldn't be an excuse), and I knew their test coverage was poor going in. I signed an NDA to start looking at their code (a Rails app), and oh god, there's SQL code in the controllers. Maybe this isn't such a good fit after all.
|
|
#
?
Jul 5, 2018 20:24
|
|
|
manero posted:oh god, there's SQL code in the controllers. noooooooooooooooo
|
|
#
?
Jul 5, 2018 20:31
|
|
|
bvj191jgl7bBsqF5m posted:Just go home for the rest of the day imo About to  They eventually came back but then, oh look, it's my lunch break. Now I've got a therapy appointment, and I was just like, and I'm not coming back until tomorrow when I said I had an appt during scrum
|
|
#
?
Jul 5, 2018 20:45
|
|
|
Taffer posted:Tech debt removal and testibility and good architecture have very high business value, it's just indirect instead of direct. If your PO doesn't understand that they're an idiot and shouldn't be a PO. At my new job there's a dedicated tech debt removal epic that the PMs throw a few stories into every sprint. It makes me happy.
|
|
#
?
Jul 5, 2018 21:02
|
|
|
Pedestrian Xing posted:At my new job there's a dedicated tech debt removal epic that the PMs throw a few stories into every sprint. It makes me happy.
|
|
#
?
Jul 5, 2018 22:54
|
|
|
Taffer posted:Tech debt removal and testibility and good architecture have very high business value, it's just indirect instead of direct. If your PO doesn't understand that they're an idiot and shouldn't be a PO. My team recently did some tech debt pay-down, and were able to immediately show it's usefulness by quickly implementing a couple useful features on top of the new code. Stuff like that is PO crack. I'm planning on using that as a model for how we tackle tech debt for now on. Today's Refactoring is Tomorrow's Feature.
|
|
#
?
Jul 5, 2018 23:03
|
|
|
I can't tell if I didn't articulate well enough the value I was adding by addressing technical debt or if the CEO was just too stupid to understand it (and money too tight) when I got laid off from Experts Exchange, but I always speculate it's the former, when it comes up during job interviews. Bonus now that I can say, "You'll have to ask the guy who laid me off, but you can't, because he has since resigned in shame."
|
|
#
?
Jul 6, 2018 00:14
|
|
|
lifg posted:My team recently did some tech debt pay-down, and were able to immediately show it's usefulness by quickly implementing a couple useful features on top of the new code. Stuff like that is PO crack. I'm planning on using that as a model for how we tackle tech debt for now on. Today's Refactoring is Tomorrow's Feature. This has always been my approach. Every new feature starts by cleaning up the existing code that it touches. This began as a self-reinforcing plan (I know I won't come back and do it after the feature's done) but it works up the chain as well. Obviously I won't spend like a week on it or anything, but I might throw an extra day or two at cleaning up if it's really in a nasty state. This works really well for bugs also - "Oh, I had a hard time isolating the behavior, so I started simplifying the code around it".
|
|
#
?
Jul 6, 2018 03:16
|
|
|
To be proactive about tech debt we've instituted a code-neutral policy. New lines of code must pay for themselves by deleting as many or more lines of code. If you want a new feature you have to pay for it somewhere, either by making existing features more efficient or by cutting ones that contribute more to tech debt than they generate in value. At this rate we'll have the company's technical debt down to zero in no time.
|
|
#
?
Jul 6, 2018 03:48
|
|
|
That is extremely temporary I hope, and ill-advised if it isn't.
|
|
#
?
Jul 6, 2018 04:27
|
|
|
Clanpot Shake posted:To be proactive about tech debt we've instituted a code-neutral policy. New lines of code must pay for themselves by deleting as many or more lines of code. If you want a new feature you have to pay for it somewhere, either by making existing features more efficient or by cutting ones that contribute more to tech debt than they generate in value. At this rate we'll have the company's technical debt down to zero in no time. Ah, your company follows the Donald Trump sounds-good-as-a-sound-bite approach to management.
|
|
#
?
Jul 6, 2018 05:30
|
|
|
Introducing the Herman Cain inspired 9-9-9 plan: 9 tests for every 9 lines of code, with at least 9 lines of javadoc for every public method.
|
|
#
?
Jul 6, 2018 06:18
|
|
|
Clanpot Shake posted:To be proactive about tech debt we've instituted a code-neutral policy. New lines of code must pay for themselves by deleting as many or more lines of code. If you want a new feature you have to pay for it somewhere, either by making existing features more efficient or by cutting ones that contribute more to tech debt than they generate in value. At this rate we'll have the company's technical debt down to zero in no time. I like this approach. Not enough people understand that code is a liability, not an asset.
|
|
#
?
Jul 6, 2018 07:37
|
|
|
Clanpot Shake posted:To be proactive about tech debt we've instituted a code-neutral policy. New lines of code must pay for themselves by deleting as many or more lines of code. If you want a new feature you have to pay for it somewhere, either by making existing features more efficient or by cutting ones that contribute more to tech debt than they generate in value. At this rate we'll have the company's technical debt down to zero in no time. Just put everything in one line. It'll be super efficient then. 
|
|
#
?
Jul 6, 2018 07:46
|
|
|
Clanpot Shake posted:To be proactive about tech debt we've instituted a code-neutral policy. New lines of code must pay for themselves by deleting as many or more lines of code. If you want a new feature you have to pay for it somewhere, either by making existing features more efficient or by cutting ones that contribute more to tech debt than they generate in value. At this rate we'll have the company's technical debt down to zero in no time. Until I worked with this guy, I never would have considered a code-neutral policy a reasonable approach. Now, I could be convinced to apply such a policy to select people...
|
|
#
?
Jul 6, 2018 08:05
|
|
|
I've found this behaviour as well. Mostly in people that are 'kind of senior': They know how to solve certain technical challenges, but they don't spend the time to stand back, look at the code and say 'okay, I've solved the problem but is this complexity REALLY needed?'
|
|
#
?
Jul 6, 2018 09:00
|
|
|
vonnegutt posted:This has always been my approach. Every new feature starts by cleaning up the existing code that it touches. This began as a self-reinforcing plan (I know I won't come back and do it after the feature's done) but it works up the chain as well. Obviously I won't spend like a week on it or anything, but I might throw an extra day or two at cleaning up if it's really in a nasty state. This works really well for bugs also - "Oh, I had a hard time isolating the behavior, so I started simplifying the code around it". What do you do when that cleanup is extensive enough that the rest of the team sees the size of the PR and doesnt want to try and review it? Thats been a thing that happens whenever I try and follow a heuristic like yours. Sagacity posted:I've found this behaviour as well. Mostly in people that are 'kind of senior': They know how to solve certain technical challenges, but they don't spend the time to stand back, look at the code and say 'okay, I've solved the problem but is this complexity REALLY needed?' This is right around where I am, except Ive started catching that is this too much thing early. 
Pollyanna fucked around with this message at 11:51 on Jul 6, 2018 |
|
#
?
Jul 6, 2018 11:49
|
|
|
Volmarias posted:Ah, your company follows the Donald Trump sounds-good-as-a-sound-bite approach to management. This guy gets it. kitten smoothie posted:Introducing the Herman Cain inspired 9-9-9 plan: 9 tests for every 9 lines of code, with at least 9 lines of javadoc for every public method. This is a good one, I'll bring this up next retro.
|
|
#
?
Jul 6, 2018 13:04
|
|
|
Pollyanna posted:What do you do when that cleanup is extensive enough that the rest of the team sees the size of the PR and doesn’t want to try and review it? That’s been a thing that happens whenever I try and follow a heuristic like yours. Make your refactorings small enough that people will still review them, but significant enough that they're useful and reasonable changes that can stand by themselves. Split a large refactoring into several of these. As an example because I love talking about myself, I'm currently working on an ugly migration, and my first change was "split the old code module into its own dependency specific class, create an empty new module for the new dependency (along with a comment and requisite TODO), have the original class decide which to use based on a flag (until the migration is complete and the old code gets deleted), then modify all relevant other classes and tests to ensure they handle and understand this before I start writing the new module." Technically I've changed nothing yet, but I've laid the groundwork for the NEW code I'll be writing, and neatly separated all of the gross parts out. It's a large change, but it's also an understandable one with minimal risk, and my reviewer thanked me for doing this up front. If I had left that to be a part of the new module, the resulting change would have been less understandable due to the new code and tests not neatly diffing and the size. As I write each part of the functionality in this new dependency's module, I'm stopping where there's a discrete, testable, useable area with the relevant tests, etc. The new module in total isn't ready yet, but parts of it can be tested individually with expected functionality FOR THAT PART verified. The changes are meaty enough that the reviewer will spend 5 minutes, and not have her time wasted with trivial changes, but small enough that they're understandable and no review fatigue sets in. Ultimately, it's something of a learned art, but try asking for feedback about whether people think the changes you're sending out are too large, too small, too complicated, too simplistic, etc.
|
|
#
?
Jul 6, 2018 14:13
|
|
|
Pollyanna posted:This is right around where I am, except Ive started catching that is this too much thing early. Or perhaps you're slowly becoming a senior developer? 
|
|
#
?
Jul 6, 2018 14:36
|
|
|
 LAST DAY! I LIVED!
|
|
#
?
Jul 6, 2018 15:01
|
|
|
Shirec posted:
 Go get drunk to celebrate! When does the new gig start up?
|
|
#
?
Jul 6, 2018 15:22
|
|
|
Sagacity posted:Or perhaps you're slowly becoming a senior developer?  Thats impossible, Im not capable of growth.
|
|
#
?
Jul 6, 2018 15:23
|
|
|
Shirec posted:
 
|
|
#
?
Jul 6, 2018 15:37
|
|
|
Technical debt isn't the same thing as codebase size...
|
|
#
?
Jul 6, 2018 16:06
|
|
|
Volmarias posted:Make your refactorings small enough that people will still review them, but significant enough that they're useful and reasonable changes that can stand by themselves. Split a large refactoring into several of these. If you have to tie the work to some user story or other unit stating that this all has to be done together, you can still push these operations together as separate commits. genki posted:I worked with a guy who was a prolific coder. He would generate many many lines of code and many CRs, so many that it was difficult for the rest of the team to make progress, because we had to do his CRs. They were always functionally correct, and solved the immediate problem, but each additional bit of architecture adds to the difficulty of reasoning about the codebase.
|
|
#
?
Jul 6, 2018 16:08
|
|
|
Doom Mathematic posted:Technical debt isn't the same thing as codebase size... Yeah, doesn't "you have to remove a line of code to add a line of code" just encourage increasing terseness at the cost of readability and maintainability? It sounds like you're slowly converting the codebase to be the bad kind of clever.
|
|
#
?
Jul 6, 2018 16:14
|
|
|
guys it was a joke
|
|
#
?
Jul 6, 2018 16:45
|
|
|
too real
|
|
#
?
Jul 6, 2018 16:49
|
|
|
Volmarias posted:Technically I've changed nothing yet, but I've laid the groundwork for the NEW code I'll be writing, and neatly separated all of the gross parts out. It's a large change, but it's also an understandable one with minimal risk, and my reviewer thanked me for doing this up front. If I had left that to be a part of the new module, the resulting change would have been less understandable due to the new code and tests not neatly diffing and the size. Exactly this. I only refactor modules/files that are relevant to the new feature and usually commit those changes separately (as a rule we squash when we merge so we can do things like this). So if I were to fix a bug my commits would look like: - (failing) test demonstrating the bug - code cleanup - bugfix. Of course real life is not always quite so cut and dried, so if a refactor looks like it's going to get really out of hand, I'll try to do the most useful thing while still keeping it short. For example we decided to modularize our code by feature at one point so rather than go back and move a bunch of random files around, I'll make sure that all the new files follow the new pattern and probably move the two or three most affected files to the new place. If everyone does this then the code will trend towards the new pattern and eventually there will be so little left of the old that someone can wrap up this major refactoring. As it stands there's actually some features that have never gotten moved to the new pattern, but this acts like a hint that this code hasn't been touched in a while, which is useful in its own way. Also it helps that my team isn't jerks about stuff like long PRs. Sometimes you'll see a bunch of random files get touched and someone might have to explain what files the actual changes are in (ie, "ignore these ten files, it's all style fixes") but that's about the extent of it.
|
|
#
?
Jul 6, 2018 17:19
|
|
|
|
| # ? May 17, 2024 23:41 |
|
|
Clanpot Shake posted:guys it was a jok I don't know if the fact that I didn't perceive it as a joke reflects badly on me, you, software development culture overall or all three.
|
|
#
?
Jul 6, 2018 20:25
|
|