|
is it normal to not document an API and instead tell someone to use the inspect element tool to deduce what the JSON you POST is?
|
#
¿
Jan 24, 2023 22:58
|
|
|
|
| # ¿ Mar 23, 2023 08:29 |
|
|
bob dobbs is dead posted:is it surprising? less than one would hope. should they be fed into a wood chipper? yes. this is all i needed to hear. they're also mixing integers as percentages versus floats for representing ratios between 0 and 1, which i just spent three hours banging my head against the desk to figure out. neither value is inherently discrete and they can both have arbitrary precision in theory so i really don't get it.
|
|
#
¿
Jan 24, 2023 23:06
|
|
|
Bloody posted:just write two methods it amazes me how often this idea escapes people*. what's the point of a type system if you just manually check properties manually inside the one method you implement *by people I mean my coworkers
|
|
#
¿
Feb 2, 2023 16:50
|
|
|
I begged someone to break their 1k sloc PR into multiple smaller PRs to a staging branch a couple months ago. They didn't, I merged to master in the meantime, and then they had to rebase ~100 commits of various sizes with "fix bug" messages on top of a breaking release that changed multiple function signatures. I still don't think they've learned their lesson to squash commits for rebasing and submit a sequence of smaller PRs, and it was roughly two weeks to get that PR in. The commit history is irreparably hosed from it, you can't bisect that monstrosity. I don't think scientists should be allowed to commit code unless they pass a test on how interactive rebasing works to understand the repercussions of their actions
|
|
#
¿
Feb 3, 2023 16:39
|
|
|
Powerful Two-Hander posted:im not mad, please do not commit to the repo that I got mad git cherry-pick -n 529713743 git commit -m "p2h got mad"
|
|
#
¿
Feb 10, 2023 15:04
|
|
|
my old startup job had a basically completely unconfigured JIRA which I used for grouping tickets by project and a really basic kanban board. it was nice and easy to navigate and pretty much entirely manual. my current job has a completely hosed implementation of JIRA where you can't drag issues between columns on the board, each issue has like 20 fields that I don't understand and no one uses, and the PM gets frustrated and says "it must've gotten lost in the transition to the new board" every other day why does it have to have all these buttons to group work and see who's working on what. why does the automated stuff not work. why can't I just put the subtask on the board without the epic being assigned to someone else and who configured this shitshow
|
|
#
¿
Feb 28, 2023 20:10
|
|
|
CPColin posted:Jira made me start using a WYSIWYG editor for ticket descriptions, so I canceled our department's subscription without asking anybody else first our instance doesn't support backticks to embed code with markdown. the one thing i strongly feel about wanting to put in a ticket, and it just doesn't work. the code style button breaks have the time, so issues are just plaintext most of the time
|
|
#
¿
Feb 28, 2023 20:14
|
|
|
TheFluff posted:i've rarely regretted writing good tickets (or requirement/planning docs in general) though. it absolutely sucks rear end to do, but clearly spelling out what we're doing (and what we're not doing), how we're doing it and what user need it's fulfilling is good, because writing things down usually clarifies them for yourself too and you'll forget all that poo poo in a week if you don't write it down after i wrote a design doc (the only design doc this team had ever produced), someone told me they don't like design docs because they prefer to think about the problems we solve with code, IN code. you can probably infer how well the codebase is organized and how well documented any of their idiosyncratic bullshit is
|
|
#
¿
Mar 1, 2023 02:38
|
|
|
tef posted:i dunno, i've had fun writing software with a design doc, it's just that most people suck at writing design docs, either going off on needless detail, or worse, weird buzzword astronauting stuff, or that most places require the former or the latter the good ones i have written were "here's the shape of the final result. here are the abstractions we need to build. here are what the tough parts are going to be, that I can identify right now." oftentimes those tough parts aren't solved until the code gets written because it requires having the problem and everything else in front of you. it's still helpful to know what they're likely to be as you build. the bad ones i wrote were trying to be overly prescriptive and formal. no battle plan survives first contact, so don't list every implementation detail. i find it fun to plan things at a high level like that, and it's the only way I can force other people to clarify what they want. I find it extremely useful to that end
|
|
#
¿
Mar 1, 2023 03:13
|
|
|
|
| # ¿ Mar 23, 2023 08:29 |
|
|
the place i worked which used a largely vanilla, unconfigured jira proposed automation of *physical processes* by submitting jira tickets. we'd use hooks to tie into our AWS infra to kick off layouts and builds, pass that over to the lab where things actually get fabricated, and automate tracking in this lab with jira through... bespoke python code i was supposed to learn + write for the love of god please do not try to bring jira into the real world
|
|
#
¿
Mar 1, 2023 14:46
|
|