|
gonadic io posted:any advice for breaking out of the classic loop of: doing tech debt informally, so tickets take longer, and management won't dedicate time to tech debt due to tickets always already being behind gonadic io posted:I mean that's the successful strategy I have used for previous companies I'm trying to avoid it this time I like this company but it's got the classic startup-no-more growing pains other than  i guess try to convince management of the business value. maybe if you can prove it with their own metrics, e.g, "doing this chore first would have avoided these bugs/made these tickets take half as long/whatever"if management is non-technical and business-driven, it'll probably be an uphill battle no matter what. if there are technical people involved in those decisions, it should be much easier, but if that was the case, you probably wouldn't be asking good luck. at my current job, i've actually struggled to report chores related to tech debt, because so many shittier jobs forced me to handle them through the back door
|
#
?
Sep 11, 2020 17:37
|
|
|
|
| # ? Apr 19, 2024 06:28 |
|
|
thanks for the tips all, as usual the worst technical problems are not technical problems at all
|
|
#
?
Sep 11, 2020 17:43
|
|
|
gonadic io posted:as usual the worst technical problems are caused by trying to use technology to solve nontechnical problems 
|
|
#
?
Sep 11, 2020 17:45
|
|
|
what if I programmed an AI to diagnose tech deb--oh wait they already tried that https://thenextweb.com/artificial-intelligence/2018/09/14/facebook-ai-tool-fixes-bugs/
|
|
#
?
Sep 11, 2020 17:48
|
|
|
If your management is not technical enough to know that paying down tech debt can be important*, they are not technical enough to notice that your estimates contain enough padding to apply the boy scout rule to your codebase * It can also be useless in certain cases, knowing which is which is really hard though.
|
|
#
?
Sep 11, 2020 17:53
|
|
|
piratepilates posted:redux is one of the react cases where it got super hyped up for some reason, and everyone thought it should be used everywhere always at all times for everything. cool. sounds like redux solves an even narrower problem than i attributed to it. so far i haven't encountered many cases where component-level states and props didn't do the job, maybe with the help of a callback prop to handle an api call, or a dom event that propagated to a parent component
|
|
#
?
Sep 11, 2020 18:00
|
|
|
piratepilates posted:redux is one of the react cases where it got super hyped up for some reason, and everyone thought it should be used everywhere always at all times for everything. to be fair, local state and async behavior was difficult to unit test in react for a really long time. was hard to write a test like "click this button that will trigger a mocked async api call and check to make sure it updates to show a success state" or something, compared to testing "this async action creator will dispatch a success action, this reducer will set the didSucceed flag in redux state, this mapStateToProps() will pass didSucceed from the store to the wrapped component, and this component will show a success state when passed didSucceed=true." newer, better test libraries and hooks might have fixed this to an extent? i just remember pre-redux react having to do a lotta setTimeout(fn, 0) hackery to get my tests to run in order with async behavior (i don't write unit tests for personal projects, and at work we're still using class components + a nightmarish redux-saga layer, so i don't know specifics of testing with hooks and the like) abraham linksys fucked around with this message at 18:05 on Sep 11, 2020 |
|
#
?
Sep 11, 2020 18:00
|
|
|
abraham linksys posted:to be fair, local state and async behavior was difficult to unit test in react for a really long time. was hard to write a test like "click this button that will trigger a mocked async api call and check to make sure it updates to show a success state" or something, compared to testing "this async action creator will dispatch a success action, this reducer will set the didSucceed flag in redux state, this mapStateToProps() will pass didSucceed from the store to the wrapped component, and this component will show a success state when passed didSucceed=true." i only started using it recently, but so far enzyme has been v needs suiting
|
|
#
?
Sep 11, 2020 18:04
|
|
|
abraham linksys posted:to be fair, local state and async behavior was difficult to unit test in react for a really long time. was hard to write a test like "click this button that will trigger a mocked async api call and check to make sure it updates to show a success state" or something, compared to testing "this async action creator will dispatch a success action, this reducer will set the didSucceed flag in redux state, this mapStateToProps() will pass didSucceed from the store to the wrapped component, and this component will show a success state when passed didSucceed=true." that's fair, and I've had a real blind spot to testing in react prior to about 3 years ago. along those lines I find hooks very useful in practice, but very hard to test. an approach I've seen in the past to do test things like api calls in components (pre-hooks, might be different nowadays) is to split the component in to two: the presentation component (just for rendering props and local state) and the container component (for fetching state like api data, and passing it down to the presentation component). I really liked that approach for splitting up the concerns of the components and reducing the needs of testing them down to passing in props and asserting what's rendered. edit: abraham linksys posted:(i don't write unit tests for personal projects, and at work we're still using class components + a nightmarish redux-saga layer, so i don't know specifics of testing with hooks and the like) yeah I'm really not sure either. the last time I checked, it seemed like one of the "official-ish" approaches to take was to make a dummy component just for your tests, that calls the hooks and renders the results for you to test. hopefully it's gotten less....sketchy? since then
|
|
#
?
Sep 11, 2020 18:07
|
|
|
DaTroof posted:i only started using it recently, but so far enzyme has been v needs suiting we're moving off enzyme to react-testing-library soon, probably, though i couldn't really tell you exactly why i did a couple minutes of googling and found this article that describes the problem with async testing that i've faced in the past, but also indicates that react-testing-library has a waitFor() util that solves this problem, neat: https://www.benmvp.com/blog/asynchronous-testing-with-enzyme-react-jest/
|
|
#
?
Sep 11, 2020 18:07
|
|
|
abraham linksys posted:we're moving off enzyme to react-testing-library soon, probably, though i couldn't really tell you exactly why ah, okay. you're probably dealing with a way more complex app than my typical project. i think my biggest has around 15 components, and the entire api for the data model can be expressed in 3 or 4 extremely simple functions (which are all mocked in the enzyme tests) DaTroof fucked around with this message at 18:17 on Sep 11, 2020 |
|
#
?
Sep 11, 2020 18:14
|
|
|
Xarn posted:If your management is not technical enough to know that paying down tech debt can be important*, they are not technical enough to notice that your estimates contain enough padding to apply the boy scout rule to your codebase yeah this. either you're trusted to do your job or you're not, and part of that job is keeping things maintainable. if they don't care about the irrelevant (to them) details, even better
|
|
#
?
Sep 11, 2020 19:05
|
|
|
Do not use Redux. I've made ~10 posts ITT about why it is awful, I'm not going to make an eleventh.
|
|
#
?
Sep 11, 2020 19:08
|
|
|
gonadic io posted:any advice for breaking out of the classic loop of: doing tech debt informally, so tickets take longer, and management won't dedicate time to tech debt due to tickets always already being behind this is the right way to work on tech debt. you pay it off when it starts accruing interest, ie when something needs to change and the lovely code makes it hard/dangerous/etc. having sprints dedicated to polishing turds isn't the right way. you just need to estimate correctly such that fixing tech debt is part of the estimates so that tickets won't be "behind."
|
|
#
?
Sep 11, 2020 19:15
|
|
|
or estimate like normal because you'll be wrong anyway
|
|
#
?
Sep 11, 2020 19:18
|
|
|
Beamed posted:.net core providing one ootb so that you don't have to put up with nonsense was a real smart move there was a pretty compelling if whiney blog post last year (?) that i can't find now about how that was the common ms pattern. reimplementing the successful third party libs to make corporate developers comfortable and killing any good will or motivation in the open sores community autofac was fine, why not just make that the default in asp core?
|
|
#
?
Sep 11, 2020 20:27
|
|
|
Destroyenator posted:there was a pretty compelling if whiney blog post last year (?) that i can't find now about how that was the common ms pattern. reimplementing the successful third party libs to make corporate developers comfortable and killing any good will or motivation in the open sores community I’m 1000% ok with Microsoft doing that for core infrastructure poo poo. as long as the built in (di framework/HTTP server/client/json parser/whatever) work well and are maintained I’m good, and tbh I’m glad the community is discouraged from reimplementing all that poo poo a thousand times over with highly variable quality, because that’s a waste of time for both the people writing it and the people who gotta choose which one to use
|
|
#
?
Sep 11, 2020 21:16
|
|
|
pokeyman posted:or estimate like normal because you'll be wrong anyway 
|
|
#
?
Sep 11, 2020 21:51
|
|
|
most libraries are bad. the less-bad libraries survive, at least in theory kitchen sink libraries are far more likely to be bad than something more minimal because they try to be more things for more people the npm ecosystem is perhaps an example of going too far in the opposite direction but perfection in a standard library is achieved not when there is nothing left to add but when there is nothing left to take away.
|
|
#
?
Sep 11, 2020 22:05
|
|
|
gonadic io posted:what if I programmed an AI to diagnose tech deb--oh wait they already tried that https://thenextweb.com/artificial-intelligence/2018/09/14/facebook-ai-tool-fixes-bugs/ write an ai that convinces your boss that you need to be working on whatever thing it is you want to work on. gpt-3 is pretty good at producing nice content-free medium thinkpieces and then you just have to attach a suitable title
|
|
#
?
Sep 11, 2020 22:06
|
|
|
gonadic io posted:any advice for breaking out of the classic loop of: doing tech debt informally, so tickets take longer, and management won't dedicate time to tech debt due to tickets always already being behind Make a persistent "maintenance ticket" that is never closed. Then when you find tech-debt, just shove it under that ticket.
|
|
#
?
Sep 11, 2020 22:07
|
|
|
Plorkyeran posted:write an ai that convinces your boss that you need to be working on whatever thing it is you want to work on. gpt-3 is pretty good at producing nice content-free medium thinkpieces and then you just have to attach a suitable title please read my latest medium article: please leave me the gently caress alone
|
|
#
?
Sep 11, 2020 22:08
|
|
|
gonadic io posted:please read my latest medium article: lkdsjflsdjlj sdljfl dsjf l;sdjk; flkas;'l d';pakf; lsdjk; fksa';d/ kas'kf,
|
|
#
?
Sep 12, 2020 00:58
|
|
|
"tech debt" is nerd jargon for "code i don't like"
|
|
#
?
Sep 12, 2020 01:00
|
|
|
rename the ignore list "poster debt"
|
|
#
?
Sep 12, 2020 01:03
|
|
|
Sapozhnik posted:perfection in a standard library is achieved not when there is nothing left to add but when there is nothing left to take away. mmmmaybe the problem is that if you leave any obvious gaps, you might still end up with kitchen sink libraries but now there are several of them see for example java, where despite a decently sized standard library, pretty much any non-trivial project is going to include guava, half of apache commons, and at least two logging frameworks. and god only knows how many dozens of libraries there are now for immutable and/or primitive collections, and how many thousands of incompatible Pair implementations
|
|
#
?
Sep 12, 2020 01:48
|
|
|
This is basically the story of Scheme
|
|
#
?
Sep 12, 2020 02:13
|
|
|
Sapozhnik posted:most libraries are bad. the less-bad libraries survive, at least in theory maybe, I guess? but the only evolution you can do on a standard library over time, with very rare exception, is to add things. hell even with .net core where microsoft tried to ditch a bunch of crap from .net framework that they didn't want to keep maintaining, they had to keep bringing things back in so that people would migrate.
|
|
#
?
Sep 12, 2020 03:15
|
|
|
ruby broke a bunch of stuff out from stdlib to various core gems that are installed by default but not loaded. that seemed to work ok, but tbh I don't remember the details and it may have been a disaster and i just didn't hear about it
|
|
#
?
Sep 12, 2020 03:26
|
|
|
abraham linksys posted:we're moving off enzyme to react-testing-library soon, probably, though i couldn't really tell you exactly why Switching to testing library made targeting 90%+ coverage a fun goal that feel like something that directly improves the quality and maintainability of my code. The way enzyme allows you to find elements by React components is shot, compared to forcing you to interact with the DOM “as a user would” like testing library does. I don’t know if enzyme fixed itself so you can test asynchronous hook stuff, but in testing library it’s simple. My tests are riddled with waitFor(() => getByRole(“progressbar”).not.toBeInTheDOM()) and it works great!
|
|
#
?
Sep 12, 2020 07:00
|
|
|
Sapozhnik posted:most libraries are bad. the less-bad libraries survive, at least in theory Don't you permanently complain that C++ stdlib doesn't contain X? 
|
|
#
?
Sep 12, 2020 07:13
|
|
|
I guess c++ is particularly bad at library management and it’s easier to have a small stdlib when you have a standard dependency manager instead
|
|
#
?
Sep 12, 2020 09:13
|
|
|
Xarn posted:Don't you permanently complain that C++ stdlib doesn't contain X? Yes, where X equals "support for network communications". Necessary standard library functionality should fit into one of two categories: 1. Functionality that everything needs: Dynamic allocation, strings, string formatting, dynamic arrays, associative arrays, basic operating system services like process manipulation and IO. 2. Protocols that everybody needs to agree on for meaningful interoperability to be possible: Deallocation, strings, comparison, iteration. Possibly hashing. Possibly logging, but that rabbit hole can get quite deep. My main complaint about the C++ stdlib is the fact that it made an atrocious gently caress-up of something as fundamental as strings and string processing, but it is extremely badly designed in a number of ways. Never mind the inability of C++'s originators (I will not flatter them with the title of "designers") to decide what the language's actual objectives are or who its target users are, the stdlib's design is simply bad and incorrect for any use case.
|
|
#
?
Sep 12, 2020 18:22
|
|
|
Destroyenator posted:there was a pretty compelling if whiney blog post last year (?) that i can't find now about how that was the common ms pattern. reimplementing the successful third party libs to make corporate developers comfortable and killing any good will or motivation in the open sores community the microsoft di lib only does the basic, sensible stuff and has one obvious and easy way to use it. there's still a place for autofac and co if you want to do dumb weird poo poo
|
|
#
?
Sep 12, 2020 18:47
|
|
|
pointsofdata posted:the microsoft di lib only does the basic, sensible stuff and has one obvious and easy way to use it. there's still a place for autofac and co if you want to do dumb weird poo poo yeah but the standard 3rd party libs like autofac or ninject did that fine too. i've never needed them to do more than "singleton scope" or "per request scope" and they're fine entity framework didn't offer anything compelling over nhibernate same with the logging frameworks at some point though ms spend money to make an "approved" library that covers the work that their (limited) open source contributors have built up around the platform and everyone who's spent time or effort on those libraries is disincentivised from even doing dotnet open source again. why could they not pick a winner in a space and spend the effort supporting documentation on best practices and maintenance? this isn't my fight, it just seems like a corporate decision that actively harms the ecosystem
|
|
#
?
Sep 12, 2020 19:44
|
|
|
Soricidus posted:the problem is that if you leave any obvious gaps, you might still end up with kitchen sink libraries but now there are several of them indeed, this in the past I’ve heard some people use the rule that a two- or three-line convenience doesn’t need to be API the problem is that then every project implements that convenience rather than the one library where it should be I think of this as the -[NSArray firstObject] problem, since for a long time there was public API for -lastObject but none for -firstObject so every project wound up implementing the latter in their own extension
|
|
#
?
Sep 12, 2020 19:51
|
|
|
Sapozhnik posted:My main complaint about the C++ stdlib is the fact that it made an atrocious gently caress-up of something as fundamental as strings and string processing, but it is extremely badly designed in a number of ways. Never mind the inability of C++'s originators (I will not flatter them with the title of "designers") to decide what the language's actual objectives are or who its target users are, the stdlib's design is simply bad and incorrect for any use case. yes indeed and honestly this is why I’m not a fan of the C++ stdlib sucking in ever more functionality—it’ll be done in a sucky way that doesn’t actually match any platform/OS and then the C++ fans will insist on using the stdlib version “because it’s standard” see the history of the C++ efforts to incorporate graphics and sound for examples: proposals that were outdated decades before they were written, with the explicit intent of undermining platform APIs, a one-two punch of suck
|
|
#
?
Sep 12, 2020 19:56
|
|
|
Destroyenator posted:entity framework didn't offer anything compelling over nhibernate sure it did: Entity Framework was a clone of Core Data while Hibernate/NHibernate was a clone of the Enterprise Objects Framework (to which Core Data was the successor) but really the important part is having one shared framework used by all applications rather than a different framework in every application; it means lower system footprint and incremental improvement via shared bug fixes, performance enhancements, and new features like whenever I see people saying they want to use SQLite directly rather than Core Data, the odds are that they’re going to just reimplement parts of Core Data with more bugs and worse performance, making all the same mistakes everyone else makes in implementing database access
|
|
#
?
Sep 12, 2020 20:04
|
|
|
This was my one forlorn hope when the Terminal HTML5 Brain outbreak started "Well, they'll probably standardize on a standard API for embedding each platform's built in HTML5 implementation, right? They surely won't keep taking up 300MB of memory per application with their own individually-compiled copies of Chrome? Right?"
|
|
#
?
Sep 12, 2020 20:11
|
|
|
|
| # ? Apr 19, 2024 06:28 |
|
|
entity framework is total garbage and is the one 1st party .net thing you should completely avoid
|
|
#
?
Sep 12, 2020 20:52
|
|