|
I'm going to just state that the vast majority of software developers have a big hole in their expertise, and that hole is SQL. Most would hugely benefit from a deeper understanding of important SQL concepts like execution plans (and how to analyze them), indexes and locks.
|
#
¿
Aug 27, 2020 19:29
|
|
|
|
| # ¿ May 10, 2024 19:45 |
|
|
You kids get off my lawn.
|
|
#
¿
Aug 28, 2020 07:45
|
|
|
uncurable mlady posted:we have a twice-annual hackathon, I’m on the organizing committee for this iteration. our biggest challenge has been to figure out how to keep people from sneaking in pet product features as their project Are these product features that the business explicitly does not want in their product? Otherwise, why would you stop engineers from improving your product if that's what they want to do? What's the goal of the hackathon, to produce specifically useless things? CPColin posted:Just lol at executives patting themselves on the back for the brilliant idea of addressing technical debt and spurring innovation a couple times a year, instead of constantly, and the peons acting like this is some kind of treat, instead of desperately dysfunctional. I don't really care what the executive circle jerk looks like, if I have the opportunity I'll take it. If that means a twice yearly hackathon, fine. At this point in my career though I incorporate technical debt management into feature work - if a "simple" feature takes much longer than it sounds like it should, chances are it's because there's a piece of tech debt throwing up a big wall in front of me, and I'm going to tear it down. Product people have no ability to prioritize technical debt, and they're not technical enough to know if a piece of technical debt is vital to address or just an annoyance, so they have to rely at least somewhat on our judgement. The degree to which they do that is a factor in how long I stay at a given job.
|
|
#
¿
Sep 1, 2020 16:52
|
|
|
We have quarterly hackathons. Sometimes they offer a "bounty" for doing a project they want (like if we're gearing up to use a new technology, they incentivize playing with it) but usually it's open ended. In one of the recent ones my colleague and I built a little testing tool so we could work with one of our vendors more easily (they add features or configuration to support upcoming releases and we need to test their side, and had no ability to do that in isolation). After the hackathon we spent another few days improving it to the point where it was flexible and a bit more easy to use. It's been immensely helpful. If we weren't able to bring some of the products of these hackathons into production, or at least internal use, I would only bother with either normal work, or just learning something for myself.
|
|
#
¿
Sep 1, 2020 17:58
|
|
|
Yeah that's what my post implied: that the output of the hackathon just appears in production without anyone approving it. My question was, if the goal of the hackathon is not to come up with stuff that will improve the product (eventually, after appropriate review from stakeholders and code owners, like anything else that goes into a product, which is something that I didn't think I had to explicitly state but here we are), then what is the goal of the hackathon there?
|
|
#
¿
Sep 2, 2020 20:47
|
|
|
Yeah I should probably mention that the ones my company runs are on company time, and generally people do love to get a break from the long-term product priorities that change every couple of weeks.Protocol7 posted:If done correctly a hackathon could be, if nothing else, a good source of self-improvement for developer skills, and any manager with a brain would see the value in that. Well sure. I just don't see the point of actively fending off people who do want to work on something for the product that may or may not be approved in the end, but that hasn't been allowed into the normal work stream.
|
|
#
¿
Sep 3, 2020 07:18
|
|
|
Protocol7 posted:I dunno, think there’s confusion around something else. The other goon mentioned pet projects which sounds like a PM trying to exert control during hackathons to me. Yeah, if it's PMs deciding what things are being worked on, then it's a work day, no matter what they call it. Queen Victorian posted:My old company did a “hackathon” once. It sucked. It wasn’t even a real hackathon, just a mandatory evening continuing education session in which we learned new stuff we were to implement in our new version (no hacking or experimenting involved) and were only given lovely cheese pizza and Mountain Dew and no alcohol (because the lead dev had the palate of a seven-year-old and the higher ups were being tightwads about beer or something). gently caress ALL of that. This is the kind of situation where enforced WFH saves the day, because you can sign on, mute and do whatever.
|
|
#
¿
Sep 3, 2020 17:18
|
|
|
All that makes sense, thanks
|
|
#
¿
Sep 3, 2020 23:29
|
|
|
Carbon dioxide posted:I'm a notorious keyboard shortcut forgetter and some people who'd prefer to hang out in vim all day get quite frustrated by my workflow involving some clicking around. It's kinda funny when they try to be helpful and just don't seem able to realize that keyboard shortcuts fall right out of my head again after the conversation. It's fun being able to fly through an environment like a bird, but the fact is once you progress past junior level you're probably going to be spending the vast majority of your work time doing anything but writing code. If I run into someone who spends all day in VIM my first thought is, "is this one of those people who never documents or diagrams, and is going to hand off their lovely happy-path-only code to someone else because they can't be bothered?" Someone completely owning VIM is a sight to see though, I admit it.
|
|
#
¿
Nov 3, 2020 08:56
|
|
|
downout posted:Yes, my college didn't have an explicit class on debugging. Which at the time I noted to my primary professor that I thought it'd be really helpful to have a class devoted to it. He at the time said that he didn't think it was necessary to have a whole class on just debugging. I think we ended up getting into a conversation about the usefulness of a class devoted to tooling/dev tools, etc. The issue is that what you're describing is all important for Development/Software Engineering, whereas most university programs are Computer Science. The program is not designed to teach you how to deliver software as a career. Granted, the other side of that coin is that whenever you tell a counselor that you want to be a developer, they'll say "well then, take our computer science program!" System's kinda busted.
|
|
#
¿
Nov 3, 2020 22:48
|
|
|
Even after a decade it's still wild to me how many managers seem to think that their job involves making absolutely no decisions or judgement calls. (in this case that would be, "is bringing this question to my direct reports going to cause a big derail or is it just knowledge they can transmit with human language?")
|
|
#
¿
Nov 25, 2020 22:17
|
|
|
Inacio posted:those are much nicer imo. The bulk of my career has been doing surgery on old busted products, either to fix bugs or add features (often both at once), yet every take home I've done has been some build-a-toy problem. Sometimes it's a problem that's vaguely related to the business, but even then they trivialize the problem space so much that it's effectively unrelated. I say if a company has a code base older than 6 months, "fix/improve this code" sounds a lot better, because at least that's related to the primary coding activities you'll be doing, and frankly, more companies should be evaluating a candidates debugging and analysis capabilities anyway.
|
|
#
¿
Dec 11, 2020 10:09
|
|
|
My company wants people back in the office. "We're an office culture," says the CEO. This despite: - having multiple offices spread across the country that work together constantly via slack and zoom - having hired people during the pandemic that are not within 500 miles of any of said offices - having hired so many people that at least two of the offices do not have the physical capacity to hold the new population - the obvious: the year of success and productivity from hundreds of 100% full remote employees What's amusing to me is that they've started complaining about how hard a time they're having finding good people to hire. "We pay competitively" they say, which is true, for the area. What they don't do is offer competitive benefits, one of which is now, for many many people, a full time remote option. Not that I've looked, but I also imagine that some of those companies aren't IN this area, and may offer even better salaries - the competition is no longer simply in the immediate region. I personally prefer to be in the office for the majority of the time, I like the casual conversation with my team and the ability to bounce ideas off people without forcing them into a zoom call, as lightweight as those are. And it helps me switch into work mode. But I moved to this city so I could be employable with good pay, and if I can leave, move somewhere quieter, and keep something close to my current compensation, I'd be extremely tempted. Again, not sure if I'm reading this situation right, I'm simply doing some logical guesswork.
|
|
#
¿
Apr 27, 2021 07:56
|
|
|
GI_Clutch posted:I'm part of an integration team that's been remote w/ some occasional in the field work for over a decade. Our team has shrunk quite a bit over the past few years due to departures and layoffs (from 10 to 4) and we are getting really strained right now. If I could find something with equivalent pay and let me continue working from home, I'd probably jump ship. I'd feel bad for my teammates and some others as I'm the knowledge owner on our biggest customer which we still have open projects for, and as one guy told me, "We'd be so hosed if you left," but man am I stressed. Should go without saying but don't let co workers guilt you into staying in a job that's stressing you out too much if you have a better option. If they're going to guilt you, they aren't worth feeling guilty over.
|
|
#
¿
May 10, 2021 02:03
|
|
|
MadFriarAvelyn posted:I had one reviewer have a very ageist stance during a pull request today and I'm debating whether or not to shrug it off or drop it on HR to deal with. You could always talk to the person, especially if you're in a position of seniority. Let them know that it's not an attitude that's acceptable to the rest of the team, or even just to yourself if that's not the case. Doesn't matter if you don't have firing authority, losing the respect of your peers is a legitimate threat. But it sounds like it bothers you, so ignoring it doesn't seem like a good option, and if it's the first time it's happened taking the nuclear option (HR) might be a bit much. You can always escalate if it happens again.
|
|
#
¿
May 29, 2021 23:31
|
|
|
Rubellavator posted:Going line by line through some code that is meant to audit data coming in from a source. They are called "audits" everywhere in the code except in this one 5000 line class where they guy who wrote this over a decade ago called them "edits" and it drives me loving crazy. I'm inspired: I'm going to name the next audit-related class I create "Oddits." It's not going to get through the PR process, but it'll be worth a laugh.
|
|
#
¿
Jun 24, 2021 11:46
|
|
|
Volmarias posted:Well yes, you just gave them extra money for the budget! That money will be given to an executive as a bonus for cutting costs, or allocated to a contractor that will cause at least three new, worse problems, and you know it.
|
|
#
¿
Aug 21, 2021 06:40
|
|
|
That's the one
|
|
#
¿
Sep 23, 2021 07:57
|
|
|
Sagacity posted:ah yes the old gambit where DevOps implies that engineering teams can now "manage everything by themselves" We must work for the same company. Don't forget that on top of everything you mentioned they incorporate a new shiny half-baked open source tool into the process every couple weeks and tell us it's the only thing we can use. Che Delilas fucked around with this message at 19:53 on Nov 12, 2021 |
|
#
¿
Nov 12, 2021 19:47
|
|
|
smackfu posted:“Oh yeah, those instructions are wrong, we should update them.” Sagacity posted:Don't worry, you get a month to migrate to the new tool. You have time for that, right? 
|
|
#
¿
Nov 12, 2021 23:02
|
|
|
Sign posted:Better than a 20 year old monolith comprised entirely of hacks mostly written by the guy who is now CTO My last job was kind of like this, except instead of the CTO he became combination lead sales engineer and product owner. The codebase had grown considerably (by people stapling things over top of what was there, naturally) since he'd changed roles, and he hadn't seen it for at least 7 years when I started there. The old folks in this thread might guess what tended to happen: he didn't trust any estimate we gave him, thought we were sandbagging, because his memory of the code and the customer base were both years out of date. So he gave the customer time estimates that were generally about half as long as it tended to take (usually by cutting our estimates in half), and then complained about how the customers were angry when reality hit.
|
|
#
¿
Dec 18, 2021 10:01
|
|
|
froglet posted:-snip- My approach for this kind of thing is usually to give them an answer, but not go too deep and also point them to the docs (when they exist, anyway). "Basically you just encabulate the framulator and then your cardinal grammeters will reach equilibrium... here, let me give you a link with the specifics. Let me know if that gives you what you need, I'm happy to clarify anything." Depending on the level of experience of the person who's asking the question, that may be enough, and I don't get the sense that they think I'm brushing them off.
|
|
#
¿
Jan 18, 2022 18:57
|
|
|
Aramoro posted:How do you track what you’re doing? Whaddaya think Slack is for?
|
|
#
¿
Apr 2, 2022 21:52
|
|
|
In the early days of the pandemic, everyone was trying to figure out ways to get the same benefits of working in an office, one of which was the organic/passive conversation point, and we tried the open zoom meeting thing too. It was a disaster. Hanging out on a zoom with a bunch of people only acted as a distraction, because whoever is talking is directly in your ears, no matter if they're talking to you or about a problem you're working on. It's far more disruptive than being in an open office with headphones (also distracting, but you can tune people out somewhat), unless you're going to mute zoom entirely and then what's the point of being in the open zoom in the first place? After my team being completely remote for a couple of years now, we've stopped trying to replicate the feeling of being in an office together. We get together for lunch every now and then, now that it's relatively safe to do so. We have a lot more small (not whole-team) zoom meetings to talk about specific issues. And we still have coffee break style conversations with personal anecdotes or venting about this or that, we just do that more at the start/end of zoom calls or slack. It's not the same as before, but the people on my team still feel like part of a team, not just a series of disconnected randos. People are no less productive, and at least some of us are a lot happier with the flexibility and general comfort of being home.
|
|
#
¿
May 22, 2022 15:55
|
|
|
Xarn posted:I have a feature X. It introduces a lot of engineering overhead, makes our product actively worse for users and has no actual benefit to us (so this isn't even a question of harmful to users to benefit us, like gathering personal info would be Think about this seriously: how miserable does this really make you and your team? If it causes a significant amount of after-hours calls that you have to field, or if you're getting flak for not making enough progress on other work because Feature X is sucking up too much of your time or complicating the rest of the product too much, then by all means, make a case (in a data-driven, unemotional way as suggested above). I would go through your direct manager to do this. But if it's just an annoyance, if it's something that from your perspective is only a problem for the company and its allocation of development time and money? Then my advice would be to stop caring about it, and take whatever satisfaction you can in the contributions that actually make the product better. If you can't do that, you're probably going to be stressed out a lot and I'd maybe take steps to transfer away from the product or get a new job where you can be more fully invested (but really, you're going to find bullshit like this everywhere).
|
|
#
¿
May 30, 2022 19:38
|
|
). I am not aware of any other similar SW that has this feature.
|
Truman Peyote posted:assuming you're talking scrum, estimates are supposed to be effort before the entire story is done, and is specifically not supposed to estimate time. or at least that's the "official" scrum line. when i get asked for time estimates i emphasize that there's a lot we don't know and that i refuse to be held to it, but if you need a number you can use X, where X is significantly longer than i actually expect it to take. I've found that really small stories can much more easily be translated into time. As complexity and uncertainty (and therefore points) go up, it gets a lot fuzzier and becomes "probably by end of sprint" but not much better than that.
|
|
#
¿
Aug 9, 2022 23:14
|
|
|
I hear this kind of thing from time to time and from my perspective the desire to implement something like this is a symptom of a broken company culture. It's always the same message: give developers an idea of the problems end users deal with every day. Okay so if users are having a problem every day, why is this not being communicated to the development teams in some way, or if it is, why isn't it being fixed? Are they UX/UI annoyances or bugs? Trends should be communicated to the product manager/owner who should be prioritizing fixes or changes if warranted. Are they backend failures or outages? If the developers don't already know about them from altering and monitoring, why not, and if not, at minimum their product manager again should be getting told so that they can prioritize fixes (and introducing those scenarios into the monitoring and alerting if there was a hole there). I say these things because mostly I haven't had direct control over the things I work on, and the people who are in control have been inclined to say "no, add this feature instead of working on that bug." It doesn't matter how much theoretical time we spend talking to customers, dealing with their daily problems, feeling their pain; we aren't allowed to fix it. So spending 5x the money on help desk one week out of the quarter really doesn't do anything except waste money and piss off developers. I have a better idea: put product managers on the help desk. Let the people who make the decisions experience the consequences of those decisions, see if that drives real change.
|
|
#
¿
Sep 18, 2022 03:13
|
|
|
My manager left the company recently, and their skip-level is treating me like the new manager. I'm suddenly on mailing lists and a slew of managerial meetings that have a large enough number of attendees to ensure that nothing gets decided, and I'm receiving documents containing information that I would consider sensitive or otherwise not intended for consumption by developers as a group .I've already made a good faith attempt at this kind of role, at this company, not that long ago. I hated it, everyone saw that I hated it, I wasn't very effective, and as a team we reworked the responsibilities the engineers took on and took me out of an overall lead role. I was much happier after that. The skip-level manager has not talked to me about any of this, either to discuss changing responsibilities or to suggest that I get "promoted" officially. I know that the only actual managers they have that could take on this role are already swarmed, but I don't know how actively they're recruiting for a real replacement, if they are at all. Annoying. Gotta have a conversation with the skip-level to clarify/set expectations; I'm hoping that it's just a transitionary thing, but the lack of communication from the jump isn't thrilling me right now.
|
|
#
¿
Nov 29, 2022 18:49
|
|
|
YanniRotten posted:If you're working as a manager even temporarily someone should tell you and if you're in the role for much time at all you should be having serious conversations about either a real promotion or the timeline for getting out of it. They should also let you say no and put a middle manager in the hot seat if you don't want it. To their credit one of them just asked me, if hypothetically I were to be offered the role, what would I say? So it feels like they just jumped the gun a tad. There's also some kind of hiring freeze on that was very recently instituted so they may be trying to get someone in place quickly. Being clear, they made their bed, they're trying to push the solution to problems they created down onto me and people like me. As usual. I don't plan on accepting that role or managerial responsibilities; I'm fully willing to help whoever they want in this role get up to speed, which may mean a slightly heavier meeting load. But at this point in my life, I have empirical evidence that this kind of work is not what I'm interested in. Edit: Also, the manager who left was awesome and only started looking because they're pushing return to office. So again, their problem. Che Delilas fucked around with this message at 22:12 on Nov 29, 2022 |
|
#
¿
Nov 29, 2022 22:08
|
|
|
Wibla posted:Have you considered following the awesome manager? He's got a non-solicitation agreement so alas, I have to wait until he updates his linkedin before I can put in my resume and give him a heads-up via his personal email address that I may or may not know. 
|
|
#
¿
Nov 29, 2022 23:11
|
|
|
500 Internal Server Error Due To Bad Request
|
|
#
¿
Dec 9, 2022 03:45
|
|
|
Volmarias posted:Look, I have a robust alerting mechanism. If I hear screams after I deploy, that means I should take a look on Monday. Tests would just slow me down! Tests are important, but I'm a senior engineer. Tests are for the juniors to write. (actual belief by developer of the code I inherited at my current job)
|
|
#
¿
Dec 17, 2022 06:37
|
|
|
So I put my notice at my current company at the beginning of the year, and my last day is today. In those two weeks, I've heard that 1. They're going to actually start enforcing their return to office policy with some kind of consequences, next month. 2. They're trying to figure out how to evaluate team performance; so far they've come up with the following ideas: - Number of commits - Number of PRs - "Jira tickets" (unsure if that means the number of tickets closed or something else) I knew the first was coming, that's why I started replying to recruiters in the first place. But I feel like I Matrix-dodged out of the way of the second one. Yeesh.
|
|
#
¿
Jan 13, 2023 20:57
|
|
|
prom candy posted:There are degrees though obviously. The other day our designer found a visual bug, showed it to me, and I fixed and deployed it all within 10 minutes or so. In an overly process-driven org he might've had to raise it with a PM, who would decide whether it was in need a hotfix or if it should be added to the next sprint and then it would go into Jira and hopefully without any context lost between the designer, the PM, and the developer who would eventually work on it. Then the fix would get made and code reviewed and who knows when it would get pushed to prod. There's an acceptable middle ground here in your specific example: you could have made the fix and put it up for code review in 10 minutes and sent out a slack message about a "simple one-liner, can I get a review rq?" Maybe it would have taken an hour or two for someone to get to it to review so they don't churn too much, but would that have affected the rest of your day? And no matter how simple a fix something seems, there's always the danger that you do it wrong in haste. You can still skip all the other stuff you described and fast track a small deployment. Obviously at the end of the day it's all about using your best judgement. Personally I find it's better to not take a step down the slippery slope of deciding that a particular piece of work doesn't need reviews at all.
|
|
#
¿
Feb 20, 2023 20:06
|
|
|
Wibla posted:"I keep normal office hours, and I won't be able to help you until late next week, good luck with your demo!" You mean "late this week" because we don't send messages like this until Monday morning when we're back on working hours.
|
|
#
¿
Mar 26, 2023 00:29
|
|
|
prom candy posted:I'm contracting for my former employer who I left for largely similar reasons. One of my former teammates estimated 8 hours on a ticket and my old boss smelled bullshit and asked me to do it. Took me 25 minutes. Apparently this kind of thing is commonplace and nobody in the org cares. I love goofing off but not sure I'd be that brazen about it at the height of layoff season. I usually try to over-estimate because I'm a chronic under-estimator. On top of that, the complexity of the code I've worked on throughout my career has built in me a deep level of distrust of anything that looks like a simple change. I don't participate in the Scotty method - I just very often see what appears to be a one-line change and make my estimate with the expectation that I'll need to go tracing code paths to make sure there's not some horrible side effect that will be a nightmare to diagnose.
|
|
#
¿
Jan 16, 2024 09:46
|
|
|
prom candy posted:I tend to overestimate as well, but a reasonable overestimate for this would've been 2-3 hours. Oh for sure, time estimates are almost always incorrect, often by orders of magnitude. I'm mostly thinking about the "oh this looks like a one-line change" scenario that ends up causing some nasty side effect on the other side of the codebase.
|
|
#
¿
Jan 16, 2024 17:40
|
|
|
Strong Sauce posted:I was actually coming in here to ask about this... how would one evaluate the value of WFH. For me each additional hour I spend at work (or devoted to it - a commute on even comfortable public transit is still time out of my life I have to dedicate to work) is more precious than the last. It goes up exponentially. As a thought experiment, let's say you had to work+commute 16 hours, and sleep 8, each day. No time for any hobbies, no time for family, can't go out for any reason, can't improve your prospects through education. How much would it be worth to you to suddenly get 1 hour of free time each day? I would venture to say "priceless." On the other hand, If you only worked 1 hour a day and suddenly had to work 2, that doesn't really impact your ability to do anything you want to do outside of a work context. Before remote became a thing, I was probably willing to give up at least a couple of tens of thousands of dollars in order to keep a walking commute to the office. I paid the price in higher rent, though I didn't reach my limit. That's me though; everyone's limit is personal and also depends on your environment and your current economic situation (it may be more valuable to you to save aggressively, and accept the loss of free time, for example), so there's no real good benchmark that can be widely applied.
|
|
#
¿
Mar 6, 2024 00:11
|
|
|
thotsky posted:Nah, there's legit reasons for it too. Most people aren't made to sit in a room working for 8 hours straight every day; they need to socialize, and I mean engaging in actual communal behaviors, not just hitting the pub with friends every other weekend. And some people don't need any of that for their validation or mental health. I get my socialization in the amounts, times, and ways I choose to; I don't need it forced upon me by people who, let's be real honest here, do not care about my wellbeing. I have regular calls with people I work with, it doesn't feel dehumanizing to me. Go into an office if you want it, I don't care. We can work differently.
|
|
#
¿
Mar 9, 2024 05:39
|
|
|
|
| # ¿ May 10, 2024 19:45 |
|
|
Gee that couldn't possibly be because the vast majority of searchable examples out there do poo poo like use wildcards for everything for the sake of brevity.
|
|
#
¿
Mar 12, 2024 22:51
|
|