|
Phobeste posted:They wouldn’t have any trouble, you know how many legs they have But only one finger per leg. The cockroach is at a significant disadvantage Unless the roaches of the future have hands on each leg which I simply refuse to countenance, I said good day!
|
#
?
Nov 18, 2019 03:23
|
|
|
|
| # ? May 9, 2024 22:37 |
|
|
"Do you know why <thing> isn't working?" "What do you mean by not working?" "I'm trying to use it and it's giving me some error" "What are you trying to do?" "Well I'm trying to do <process> and it's giving me an error" "At what point are you getting an error?" "Doing <thing>" "Through the UI? From another service? cURL?" "cURL" "What's the error? "I'm not sure, some kind of access error or something" "What's the http code?" "I don't know, do you need that?" "Just send me the cURL command" ... "You put -X instead of -H for a header" every day with this poo poo
|
|
#
?
Nov 20, 2019 17:10
|
|
|
The above post but with: <thing> has a bug.
|
|
#
?
Nov 20, 2019 18:03
|
|
|
Fellatio del Toro posted:every day with this poo poo I just had a coworker ask me "hey is there anything else I need to know about X?" uhhhhhhhhhhhhhh I guess just go ahead and tell me everything you know about X and then I can tell you what you don't know. I'm not a mind reader!
|
|
#
?
Nov 20, 2019 18:55
|
|
|
Fellatio del Toro posted:"Do you know why <thing> isn't working?" Severity: Critical Note: This keeps me from working
|
|
#
?
Nov 20, 2019 19:05
|
|
|
Keetron posted:The above post but with: See also: The system is down
|
|
#
?
Nov 20, 2019 19:51
|
|
|
"Hey has anyone told you yet that the system is down?" "What? Production?" "No, R&D" "It looks like everything is up and healthy" "I'm looking at the UI and there aren't any jobs running" "Are you trying to run something?" "No" "Is something supposed to be running?" "I don't know" "Are any of the data feeds turned on in R&D?" "I don't know" "If nobody is testing anything right now you're not going to see any jobs running in R&D"
|
|
#
?
Nov 20, 2019 20:00
|
|
|
If anyone walks up to me and says “the system is down” without context I’m absolutely going to stop them there and start playing that strong bad episode
|
|
#
?
Nov 20, 2019 20:14
|
|
|
"The system is down." "Down with the system!"
|
|
#
?
Nov 21, 2019 01:31
|
|
|
ultrafilter posted:"The system is down." The system has downs.
|
|
#
?
Nov 21, 2019 01:53
|
|
|
System of a Down.
|
|
#
?
Nov 21, 2019 07:46
|
|
|
Make it go!
|
|
#
?
Nov 21, 2019 16:51
|
|
|
I just pretend I'm dealing with Pakleds from that one episode of TNG. "You make ship go?"
|
|
#
?
Nov 21, 2019 17:01
|
|
|
New Yorp New Yorp posted:I just pretend I'm dealing with Pakleds from that one episode of TNG. "You make ship go?" If you want to go that route, "The real trick to this job," Argle wrapped up, "is to realize that the only four answers you ever need to give are 'Yo,' 'Oh,' 'So,' and 'No.'"
|
|
#
?
Nov 21, 2019 17:55
|
|
|
New Yorp New Yorp posted:I just pretend I'm dealing with Pakleds from that one episode of TNG. "You make ship go?" I still cannot believe that this was actually an episode
|
|
#
?
Nov 21, 2019 18:22
|
|
|
We made new teams today because the old dev teams were growing too large to be effective. I'm worried I ended up in the team that's gonna get all the work nobody (else) wants to do.
|
|
#
?
Nov 22, 2019 18:58
|
|
|
Carbon dioxide posted:We made new teams today because the old dev teams were growing too large to be effective. They chucked me on the tech debt team at my old job and they were genuinely shocked when I put in my notice. I know that probably doesn't help, but it's an anecdote, I guess.
|
|
#
?
Nov 22, 2019 19:00
|
|
|
Carbon dioxide posted:We made new teams today because the old dev teams were growing too large to be effective. Go talk to whoever made the teams and tell them how excited you are about [technology used on the team you want to be on] and how that will enhance company revenue, and try to get on a different team. Now is the time, before things become solid.
|
|
#
?
Nov 22, 2019 19:40
|
|
|
taqueso posted:Go talk to whoever made the teams and tell them how excited you are about [technology used on the team you want to be on] and how that will enhance company revenue, and try to get on a different team. Now is the time, before things become solid. That's the thing, we made the teams ourselves. It worked out fantastically the first time we did that, a year ago. Put people in random groups, have them rate themselves on some axes such as pragmatical/theoretical, starter/finisher and so on, and keep shuffling people until each team is balanced. This time we did a similar thing except we split up the teams we already had randomly and then did the axes balance thing again. Partially because of me saying that it worked so well last time. After the random split up, things were balanced along those axes quite well and we discussed some other things like expertise knowledge too and at this point, no amount of shuffling would've improved the overall distribution of the new teams so I decided to accept it for now. My manager is a decent guy, knowing him if it turns out I really am not happy in this position after trying it for a couple months, I can talk to him about switching teams. Especially if the plan to hire more people works out, because then we'll have more shuffle room. We'll see.
|
|
#
?
Nov 22, 2019 19:52
|
|
|
I love refactoring, being in a team that is dedicated to clean up and actually gets time and budget to do so sounds pretty good to me. Much better than having management breathing down your neck for features that cannot be delivered because of said tech debt.
|
|
#
?
Nov 22, 2019 21:16
|
|
|
Protocol7 posted:They chucked me on the tech debt team at my old job and they were genuinely shocked when I put in my notice. I know that probably doesn't help, but it's an anecdote, I guess. Some people like working on tech debt. I do because I don't generally give a poo poo about the latest whizzbang feature that a random customer or prospective customer wants (usually because it breaks the laws of space and time as we understand them and also the requirements are always vague at best and the opposite of what they actually want at worst). At my last job I updated our dependency management from "check versioned .dlls into source control, manually manage the files and version numbers in 50 places if you ever want to update (so we never update)" to "update from Nuget on build, if necessary)." It was a huge project and I learned more about WiX than I ever wanted to know, but it let us do crazy things like add libraries to our solution or update a library that was 10 years out of date and had a million security flaws, without wanting to kill ourselves. It was great and I'm pretty proud of it. I've also heard this described as "v1 developer" vs "v2 developer" which I kind of like.
|
|
#
?
Nov 22, 2019 22:09
|
|
|
I would love to be on a tech debt team. That’s just getting paid to be judgy about other people’s code.
|
|
#
?
Nov 22, 2019 23:06
|
|
|
I've spent the last couple years doing maintenance or supporting other people's codebases. It loving blows and I'm sick of it.
|
|
#
?
Nov 22, 2019 23:56
|
|
|
lifg posted:I would love to be on a tech debt team. That’s just getting paid to be judgy about other people’s code. No, it's taking ownership of lovely code and being responsible for unshitting it without breaking it. Been there, done that. Awful.
|
|
#
?
Nov 23, 2019 00:15
|
|
|
Nothing encourages a team to write bad code like knowing another team is responsible for cleaning up the mess.
|
|
#
?
Nov 23, 2019 00:38
|
|
|
Less Fat Luke posted:Nothing encourages a team to write bad code like knowing another team is responsible for cleaning up the mess. Which is why they should be reminded at every opportunity: Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live
|
|
#
?
Nov 23, 2019 01:17
|
|
|
New Yorp New Yorp posted:No, it's taking ownership of lovely code and being responsible for unshitting it without breaking it. Been there, done that. Awful. Our team got roped into all sorts of stupid discussions and PRs because we “touched that code” and “might know something about it.” Blamed for build errors when the log indicated an error from a file I know for a fact our team did not touch (we shared dev environments for our teams on some projects!) So on and so forth. Plus the whole judgmental part does not give you a healthy viewpoint of your peers. We know the ones who suck, but you don’t need a constant reminder.
|
|
#
?
Nov 23, 2019 05:58
|
|
|
Less Fat Luke posted:Nothing encourages a team to write bad code like knowing another team is responsible for cleaning up the mess.
|
|
#
?
Nov 23, 2019 17:08
|
|
|
Protocol7 posted:Our team got roped into all sorts of stupid discussions and PRs because we “touched that code” and “might know something about it.” Blamed for build errors when the log indicated an error from a file I know for a fact our team did not touch (we shared dev environments for our teams on some projects!) So on and so forth. Taking this in a different direction: Getting stonewalled from fixing the code because the original developer takes it as a personal affront.
|
|
#
?
Nov 23, 2019 18:20
|
|
|
Opinion for a newbie developer - I need to add a new feature that is adjacent to functions in my application. Is your preference to: A) loop the adjacent feature into your current functions and invent clever ways to use the code that exists, though it may not fit perfectly? B) add the new feature to the side, growing the code base but allowing independent support for both? C) refactor the code a bunch to find a balance right between the two?
|
|
#
?
Nov 23, 2019 21:15
|
|
|
Judge Schnoopy posted:Opinion for a newbie developer - I need to add a new feature that is adjacent to functions in my application. That question has a lot more baggage that you may realize. You will probably learn more by picking an approach and learning from what specifically becomes easy or hard when you follow through on it than by fretting over whether you're doing it right. "Functions" and "features" in an application are concepts that exist on wildly different scales, and thinking about them at the same time strikes me as an indication of a more deep-seated confusion.
|
|
#
?
Nov 23, 2019 21:21
|
|
|
I might just be trying to oversimplify the explanation. There exist functions that pull info A. I need to pull info B in a similar but different way. I could probably try to use functions that get A to get B too, but would conflate the primary use case and lead to complications if I try to refactor later. I could also duplicate code from functions getting A, change the bits that need to be changed, write new tests, and support both use cases separately. This would add a lot to the code base but sounds easier to maintain. Or I undergo a lot of refactoring now to take the duplicated parts from A and B into separate functions to be the most reusable. Which really sounds like the 'right' choice but is the most amount of work. So I'm asking for opinions from people who have done this a lot longer than I. Where would you tend to land?
|
|
#
?
Nov 23, 2019 21:34
|
|
|
If you're not sure, start by duplicating it, and look for opportunities to deduplicate once you can see clearly what they have in common. Think about what's essentially identical and what's just coincidentally identical.
|
|
#
?
Nov 23, 2019 21:39
|
|
|
It's hard to say without specifics but at the broadest, most general level, my experience is that it is easier to write new code and tests that do one specific thing than it is to cram new functionality into code that was never intended for it.
|
|
#
?
Nov 23, 2019 21:40
|
|
|
Bongo Bill posted:If you're not sure, start by duplicating it, and look for opportunities to deduplicate once you can see clearly what they have in common. Think about what's essentially identical and what's just coincidentally identical. This. We love to emphasize DRY, and most student code I see could use more of it, but you should avoid factoring out code that is identical only accidentally.
|
|
#
?
Nov 23, 2019 23:14
|
|
|
Vulture Culture posted:Counterpoint: knowing that literally nobody will ever be responsible for cleaning up the mess Obviously it comes down to the culture of where you work and how much engineering time is valued versus maximized.
|
|
#
?
Nov 23, 2019 23:27
|
|
|
If you're a newbie a good rule of thumb is to not make abstractions until you have three concrete examples to abstract. Also a decent rule for non-newbies
|
|
#
?
Nov 23, 2019 23:32
|
|
|
Good post on the subject: https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction
|
|
#
?
Nov 24, 2019 00:21
|
|
|
Judge Schnoopy posted:Opinion for a newbie developer - I need to add a new feature that is adjacent to functions in my application. Which answer sounds like the least likely to be a nightmare when you have to modify that code in three years?
|
|
#
?
Nov 24, 2019 06:49
|
|
|
|
| # ? May 9, 2024 22:37 |
|
|
Bongo Bill posted:If you're not sure, start by duplicating it, and look for opportunities to deduplicate once you can see clearly what they have in common. Think about what's essentially identical and what's just coincidentally identical. This is a good insight, thank you for it.
|
|
#
?
Nov 24, 2019 10:08
|
|