|
Vulture Culture posted:Ggaanntt sounds like a guy who's been making visual kei music since the '80s  No offense to Mr Gannt, but it's a challenge to find five people who know how to spell his name and he should have chosen something better. It may not be his fault; being the early 20th before we chose buzzword names for everything, perhaps some peer just started calling it the Gantt chart. I have to trust that by typing ggaanntt I have a 25% chance of doubling at least one of the letters correctly!But I prefer PERT charts generally. Falcon2001 posted:At a previous job there was an org that decided one day that they wanted to do 24 hour rotations, despite having a follow the sun team. In sadder news, because of the holiday many took off Thursday so I had to delay a week. I was going to talk about some software theory and some mathematics we used to justify not doing something, because an engineer on the team asked how we got our numbers. More theory!
|
#
¿
Mar 1, 2024 15:25
|
|
|
|
| # ¿ May 11, 2024 10:13 |
|
|
Replying generally to all of the above, and as anecdotally as the others. Neither WFH nor in office work forces you to be "friends" with your coworkers. If you've worked in an office you know this is a laughable assertion by the types of arguments that come up (temperature/lighting/music being the least troublesome). In office makes it easier to achieve "friendliness" because you're less likely to interrupt someone who is clearly busy; WFH still has a huge mess of competing mechanisms where it's unclear what constitutes an interruption. WFH has empowered increased laziness with technical communication. When a team has at least one person in authority who refuses to use written communication --- ie every team --- wfh becomes call center hell, just waiting for the next "let's have a quick meeting about it!" preventing you from starting focused work. In office those types tend to schedule meetings instead with suitable warning, and historically learned to write poo poo down because they had no expectation of getting quick chat answers when they were sitting in meetings with their bosses and didn't have the answers. In office does require different personal presentation and planning, but I disagree that WFH is a free-form mental vacation: You can't just take a walk because those external activities cause real unexpected delays. In an office "well it's lunchtime don't try to do stuff 5min before lunch" is easy to fix because teams tend to notice who takes off for lunch regularly. More likely with WFH is "well they aren't responding, don't use status settings, they might be walking a dog or themselves or at lunch or gone", so many 1-2hr tasks have become daily-turnarounds. (And, sure, people should "use status and it's all fixed", but the point is that people simply don't). Daily standups solved the issue of proximate teams being so busy that simple tasks would lose priority (did you forget to review my doc?). We don't even need dailies anymore because now everyone expects to need to follow up since schedules are entirely randomized (I'll check back in 24hr if they haven't responded, but not "in the morning" or "after lunch", but wtf some random time for every task and every different person). I've hated WFH since the beginning. It works when you're sick, or if you have a half day medical appointment to focus on, but office productivity is so much greater, better ergonomics, better work setup, presentation screens, white boards. To those who don't want to deal with forced social contracts in offices, I say to you I don't want to bring work into my home, period. It's an invasion having to keep that social masquerade up in my home, to have gear on my table, to mentally loathe that space because of a bad meeting or interchange. Work needs to be "other", way over there in that office, something considered when in that space, restricted to those times.
|
|
#
¿
Mar 10, 2024 17:29
|
|
|
Many topics but someone said it well above: Meet people where they're at. Environments, programming languages, procedures, and processes all produce anti-patterns and substandard behaviors naturally because of their flaws. In an office, people naturally feel empowered to walk up to someone's desk. Last week an engineer approached me, stood for 20 seconds before taking a nearby chair, and then sat patiently for another half a minute before I concluded my task and was able to assist them. Someone in authority interrupting almost always has a reason, but if not they would need an adjustment. Remotely, people naturally feel more empowered to have an adhoc full meeting. That is, once they have you responding in chat, they give up and escalate to "needing" a full demonstration. This is a pattern that some have adopted permanently, to the point of announcing it as a viable technique for ongoing project management. To them I say, no, at least 80% should be improved documentation. Demonstrations need to be scheduled so people can prepare any relevant materials and so others can prepare their questions. Otherwise it will mostly be a waste of time. And quite frankly just because I can type in chat does not mean that I'm presentable for a meeting, which would be true if I was working from home or logged in early to deal with an issue. Both environments can be improved, but the types of issues encountered are different.
|
|
#
¿
Mar 11, 2024 15:53
|
|
|
I for one welcome... Wait I'll restart: How have things changed when your team has been approved to use ChatGPT+similar for software questions? I realize that its sources are not dissimilar from stack overflow, but based on a past run through I did with someone, we found its solutions rather incomplete and non-functional. What I foresee is a notable change in effort: Those who use AI posting more code (LOC meh), while reviewers spend much more time explaining that the submitted algorithms are an utter mess. AI! Make lazy people lazier, and productive people overworked remedial software educators!
|
|
#
¿
Mar 12, 2024 22:18
|
|
|
Oooo thank you! I'd even go so far as to believe that languages more discussed online have fewer AI blunders; ie they can filter all the irrelevant SO answers more quickly than a human reading. Alas, I suspect accuracy drops off precipitously.
|
|
#
¿
Mar 13, 2024 06:31
|
|
|
The true pareto chart: 500 lines per hour (lph) of production ready code, tested and validated, performance and memory profiled 350 lph after explaining software best practices to paired peer 97 lph after manual style guide application 40 lph after team lead takes a look and decides "we don't need helper functions, separation of responsibility, testable code" 35lph after explaining to team lead: SOLID, basic encapsulation, and how code is not easy to read if names are global across a 1M line codebase 22lph after team lead asks two or three other leads to pile on with their opinions 14lph after deleting all of the above so the code can get "approved for release" sometime in the next couple weeks 11lph after two last attempts to hit the Yes/No black box that "owns" the code but can't describe what they want, only how things aren't what they'd write 8lph after the reviewer finally gets around to looking at things that matter in the code, and simple changes are now exceedingly difficult because all of the above made the solution unmaintainable and not clean code 5lph from having to redo all tests and profiling half a dozen times 4lph after recovering from the liquor+drugs necessary to destroy the last semblance of your creativity
|
|
#
¿
Mar 14, 2024 01:33
|
|
|
Thanks all. I think we'll know in a couple weeks who takes this opportunity to become even more lazy.Rocko Bonaparte posted:... A friend was working with her daughter on some translations and it was invaluable. They still had to correct it but it presumably did much better than standard translation tools.
|
|
#
¿
Mar 18, 2024 06:30
|
|
|
What's the term for not-actually-gaslighting but engineers being repeatedly blocked from sending working and validated code to production, having release mechanisms where individuals don't use approved PRs but decide they want to reinvestigate all the code and make new complaints, being unable to follow industry best practices and standards for engineering such as proposals/designs/documentation/prototype sharing/bugfix cycles and instead needing to revert working solutions and regress projects, engineers needing to go to leads to explain how to improve the planning process and then (being told it's fine as is but there is still an unmeasured expectation of "completion") needing to demonstrate basic task ownership/grooming/planning...? The most recent drop-dead-laughable was an engineer that shipped the code and, the next steps being privileged-only on-host script execution, just for staging verification mind you, assigned to the lead with the steps, was reassigned the ticket by the lead, eng returned after a one day absence to find the work not yet done, reassigned to another lead with more familiarity, who was on vacation but logged in to reassign it to the first lead, who  reassigned it to the engineer again, who wrote up instructions again (the first being buried in two pages of needless noise) and reassigned it to a privileged manager. Then the first lead jumped back on the ticket to dissect the second set of instructions, with a paragraph per step (either reiterating what the engineer said the first time, or complaining about where the steps were recorded in jira, not sure I ran out of time to decipher their mess). All this for what amounts to less than five minutes of actual work.Unfortunately I'm not in a position to fix all these situations, but the calendar is going to soon be full of meetings getting these confused people into a room every time they need to actually behave like leads and help their engineers release code.
|
|
#
¿
Mar 28, 2024 01:56
|
|
|
ElehemEare posted:“We’re agile!” in the job posting. (* The spelling, not the process.) 
|
|
#
¿
Mar 28, 2024 02:41
|
|
|
Ah the tyranny of the short sighted mba program. Raise your hand if you've ever used documentation for a programming language? (100% minus the liars). And if you use any source that's written text during software work at least once a week? (Yeap SO is centralized code comments and cookbooks). And if you've ever onboarded anywhere and learned anything reading a document? Whelp... Then ensuring everyone must come to you for knowledge must just be job security.
|
|
#
¿
Mar 28, 2024 23:34
|
|
|
Our engineering VP goes on sabbatical soon, but as yet the team leads are still in the stone age. The new manager gets that workload and was very clear that the teams are answerable for fixing broken processes, lack of clear project goals, deadlines, estimates, it's on the teams to make something work. Engineers on one team took the initiative, used this chance to share ideas about what to improve in the next few months. Yesterday the lead told one of the 5yr engineers on the team that they had to change how they reviewed code. Production libraries, one off simple scripts, prototypes,... after four weeks of being told to focus on what matters, the highest priority for the team: Code style according to a manual checklist that the lead doesn't even follow. I asked the engineer if they agreed that was the highest priority. Naup. Enough is enough. Lead won't listen to or engage engineers on the team, doesn't trust them, give them space to grow, doesn't even seem to know role responsibilities in the org.
|
|
#
¿
Apr 19, 2024 05:38
|
|
|
|
| # ¿ May 11, 2024 10:13 |
|
|
Vulture Culture posted:I'm not sure if this is just ranting or looking for advice, but here's my thoughts: I don't quite understand your questions, however (a) discussions have suggested the manual nature of what's being requested will add 15-20min per hour, and historically it's been more since the requests have actually contradicted the guidelines. Since it's now being claimed as an impediment to any discussion, coupled with the lack of a design review it means that engineers will be throwing out a lot more code. (b) Seems like a "stopped beating wife" question. It's nearly gaslighting behavior as engineers, including those onboarding, are being told to uphold a policy but asked for different results after doing so. It's not a matter of individual perfection but the lack of metrics, associated goals, the unattainbility of 100% perfection, and the deviation from those norms in the present code base. In fact engineers have no avenue to make suggestions and past questions, since the document is necessarily incomplete, have gone unanswered. I'm strongly in favor of teams making improvements. Cultural changes are difficult and take time. Leads ideally will empower engineers and unblock them by building better solutions, not leaning into manual, highly subjective and anecdotal processes.
|
|
#
¿
Apr 22, 2024 03:56
|
|