|
Guinness posted:this could be the thread title 
|
#
¿
Sep 29, 2022 07:09
|
|
|
|
| # ¿ May 13, 2024 08:26 |
|
|
Meta's campus sign is built on the old turned-around Sun Microsystems sign. This is apparently a memento mori to remind employees to stay humble/hungry because even huge companies can disappear quickly. Looks like that's gonna come true.
|
|
#
¿
Oct 5, 2022 18:02
|
|
|
Yeah, I've never seen anyone go "Ah, that was a great proof-of-concept and we learned a lot. Now time to chuck it and start again on the real program!" Ofc the POC is just going to evolve into the final program. That's why exploratory program should be somewhat structured; to avoid architectural dead ends and needless refactors. TDD can help as scaffolding to coerce you to consider your inputs / outputs / data structures, and to build testable code... but like real scaffolding, you take it down when the building is strong enough to support itself. You probably don't need the entire corpus of tests you developed as you were still exploring how to build your program; you just need a key few.
|
|
#
¿
Oct 25, 2022 05:27
|
|
|
The most frustrating thing I find about tests is that so much of it is in subjective grey areas. There's all this advice "do it this way, but sometimes it's better to do it that way", "you can write too {many,few} tests", "flakey tests are bad but can sometimes be better than nothing", etc, but it seems to be a total art to drawing where those boundaries are. With almost every other part of programming the app itself, I can have a reasonable discussion about coding styles and code architecture. But when it comes to tests, all these decisions feel capricious. If I have a flakey test, do I nuke it, fix it, or ignore it? Based on what? If the answer is "how important is that scenario in the system under test?" then how does one measure that?
|
|
#
¿
Oct 27, 2022 02:32
|
|
|
leper khan posted:If it costs more in maintenance than it saves in product risk, it should be removed.  leper khan posted:Both of these things are measurable.  I don't think they're always measurable, I don't think they're often measurable, and when they are, I doubt many people make the effort to measure them. I agree you can put a $ cost to some things (like GDPR compliance), but even then, that's not something I'd expect every engineer to know. I don't feel most engineers are writing tests with direct tangible & measurable benefits. When I'm authoring any test, I'm making many small judgement calls with poor data and zero rigor. If I'm lucky I'm asking: - how much is this going to cost to write? (Code might need to be refactored if it's not in a testable state) - What will the program do if no test existed to catch this scenario? Crash or do something crazy, or just be a cosmetic problem? - What's the business impact (in $$) or loss of customer goodwill this test is saving us? - how likely is the system under test going to change in the future? (This affects my ongoing maintenance costs.) - How fast can we deploy a fix if I don't bother to write a test here? If I'm looking down the barrel of a failing/flakey test: - What's the estimated cost of fixing this? 5 mins or a week or more? - How important is this test anyway? (Whoever wrote it didn't comment explaining their judgement, so now I'm second-guessing them. And maybe the situation has changed since the test was written.) - How flakey is this? If it's < 1% can I just get away with wrapping it in a "retry 5x until pass" wrapper or is that going to piss off the test purists? - How expensive is this to run? (We have some CI E2E tests that take hours) Can I just nuke it? I don't think any of these judgement calls would be consistently applied across tests, let alone across an engineering team, or over time. Unless you're building Therac-25's successor or some PCI processing code, I feel I might as well answer them by rolling dice. (Hell, I'm guilty of simply nuking troublesome tests just because I was tired and grumpy. Not a very principled way to run a codebase.) ultrafilter posted:Testing is an art and it's something you get better at with experience. I know that's not an incredibly helpful answer but it's the truth.
|
|
#
¿
Oct 27, 2022 05:07
|
|
|
Rocko Bonaparte posted:I feel like I could get into the game of stupid software engineering thought leader stuff if I published a book called "Anxiety Oriented Programming" where I make the thesis that the main goal of any development process should be to reduce the anxiety in the project and instill some sense of confidence, and anything in the process that instead increases that anxiety needs to just get thrown the gently caress out. 
|
|
#
¿
Oct 27, 2022 13:18
|
|
|
Feels like Goodhart's Law in action. As seen at Google, Facebook, and other places where you need to demonstrate your impact to get a good performance review, people optimized their career to focus on tangible impact; where they could point to Good Number Went Up, Bad Number Went Down. But that left out the other essential work with no metrics - like, cleaning up TechDebt, or keeping systems up to date, or being a subject matter expert. (Infamously at Google, the trick was to work on a product until it launched then immediate switch teams, because "Launched Product X" looked good but "Maintaining Product X" didn't, resulting in many products lacking maintenance. Apparently management had to put in policy to stop people doing this.) SREs have a hard time with this because their whole job is to keep things stable. "Number didn't go up or down" is actually work. SREs doing perf reviews sometimes feels a bit like the Pool Supervisor sketch from The Day Today. "In 1976, no-one died. In 1977, no-one died. ...." https://www.youtube.com/watch?v=ob1rYlCpOnM
|
|
#
¿
Nov 18, 2022 20:16
|
|
|
LLSix posted:having a computer that will follow instructions far more reliably ChatGPT3 seems to reduce the time spent doing the latter, just as a junior (or "dumb") programmer might. It's not perfect, I can't just turn my brain off and blindly accept its output. But it might get me 80% of the way there very quickly. Case in point: I ran into https://text2iam.com/ today, which lets you type in human-readable descriptions of AWS IAM policies, and uses GPT3 to generate policies that map to that. One example from their page: "Allow full S3 access if user has used MFA within the last 30 mins". Writing that policy from scratch by hand would require a lot of thought and careful research. Using this system, I could get a policy quickly and then review it to see if it works as expected. It doesn't replace me or my knowledge, that's still essential. But it would save a lot of time.
|
|
#
¿
Dec 5, 2022 05:37
|
|
|
I realize that must feel good, but tbh I assume no-one reads anything and conclusions should be put in the first line. "TLDR" / "BLUF" (bottom line up front) is like a super-power when convincing people to do anything.
|
|
#
¿
Dec 7, 2022 18:12
|
|
|
luchadornado posted:stop trying to make BLUF a thing - it's not happening
|
|
#
¿
Dec 7, 2022 20:02
|
|
|
I much prefer Python over Go for most of my tools. I find Go useful for writing statically-linked self-contained cross-platform binaries. But Python is what I reach for when I need a quick and/or dirty throwaway / prototype. If you're doing system programming, maybe choose Go. Anything else, including webdev, I'd go for Python.
|
|
#
¿
Jan 4, 2023 19:01
|
|
|
Re: features, that's the 10% of the engineering you see. The other 90% is infrastructure & operations.epswing posted:When you say "crazy hiring", are you referring to expanding engineering depts? Maybe they're kinda the same size and personnel are just rotating through?
|
|
#
¿
Feb 8, 2023 16:07
|
|
|
Steve French posted:Am I crazy for thinking that for a 3 month project the idea that you can measure whether you’re on track with 2-3 day precision is absurd unless you’re at the end of the project? I guess OP didn’t mention how far along the project is Yeah, this. In my experience, estimates are only as accurate as T-shirt sizes, certainly can't pinpoint them to days/hours worth of effort. The big value of estimates is when there's lack of consensus: if some believe the task is Big and others believe it's Small, that suggests someone's working off incorrect assumptions / information.
|
|
#
¿
Mar 20, 2023 18:16
|
|
|
Comb Your Beard posted:Got put on a PIP beginning of March, I thought I had really turned it around crushed it last month, turns out I'm fired anyway. Turns out at a lot of places, PIP == "HR is putting together the documentation necessary to cover the company's rear end for when they let you go" and you never really had a chance.
|
|
#
¿
Apr 10, 2023 22:55
|
|
|
Pollyanna posted:I don’t feel like a good dev 
|
|
#
¿
Apr 11, 2023 19:17
|
|
|
Startyde posted:I offer to purchase The Mythical Man-Month for anyone above or across me and have been doing so for the better part of twenty years. Don't think it's worked one god drat time but I've gotten some interesting books in return so buy them 2 so they'll read it faster
|
|
#
¿
Jun 29, 2023 20:59
|
|
|
I do not care about gaps. Gaps can happen for all sorts of reasons: looking after yourself, a new or aging family member, moving across the country, all sorts of things. It doesn't signal to me "was looking for work but couldn't get an offer because they're no good". I do care about duration of employment. I know it's common these days to job-hop every 2 years, but I feel that someone who has stayed at their last couple of jobs for 5+ years is likely a better candidate than someone who moved every 2 years.
|
|
#
¿
Jul 6, 2023 16:57
|
|
|
Ensign Expendable posted:I hopped my way through a few consulting hellholes and then a series of constantly collapsing startups, it probably raises some red flags. I still quit my previous job a year and a half in because my manager was a colossal piece of poo poo and everyone up to the CTO checked out and was actively looking for a new job themselves. But also when evaluating someone, we're looking at so many other signals that are much stronger. Job duration is just one signal, and it's weak. It might be a contributing factor if we're on the fence about someone; but it's not going to come up if they demonstrate strong engineering skills, are good communicators, demonstrate pro-activeness, etc etc. Re: taking some time off for travel. My recommendation is to not plan too much; otherwise the vacation becomes Work, where you're constantly scheduling and trying to optimize seeing the most sights on the smallest budget within the allotted time. It ironically becomes stressful. If you have the money, I'd highly recommend doing it. Don't wait until your older when you'll have less energy and more responsibilities that will reign in the ability you have now. I know some folks who took "pre-retirement": quitting their jobs for a year to go do all the fun stuff that'd be too hard to do once they had kids and/or older-age health issues.
|
|
#
¿
Jul 6, 2023 19:15
|
|
|
Ensign Expendable posted:I spoke to a lot of people around my level who also wanted to quit but felt like they should stay at a company for X number of years just out of principle. Fine: "Company leadership was struggling to find a working strategy for our product, and soon it was clear the writing was on the wall. I felt I wanted a better opportunity to make impact with my skills, which is why I left." Bad: "Ugh, the marketing folks there thought they were god's gift to the world and wouldn't listen to anyone, they were so dumb that they drove our product into the ground. They probably don't care, they're likely all still doing coke in the bathroom"
|
|
#
¿
Jul 6, 2023 19:24
|
|
|
Artemis J Brassnuts posted:Have we got any software security peeps around? I’ve always been interested in it (decompiling, pen testing, etc) and I’m considering making a pivot to it because I’d like to get involved in more meaningful things. I’d be grateful to hear any takes on the topic, required reading, learning resources etc. Sign posted:I did some blue team stuff for a while. I found it exhausting because I would repeatedly spend my time working with the worst teams who would say things like "well do we have to encrypt that (SSNs)? It will take too long to make that change." And they'd spend weeks ignoring me and trying to get an exception and complain we're making them late. InfoSec is certainly interesting. There's innovative technology & techniques, lots of drama, many war stories. But from a job-satisfaction POV it can be disheartening because InfoSec groups are constantly having to cajole unwilling users who just see them as irritating friction. And it's worse in a company where InfoSec have no real teeth to enforce recommendations.
|
|
#
¿
Jul 21, 2023 15:30
|
|
|
Some interviewers know they need to ask some technical questions, they don't really know how to test a candidate, so they come up with some questions they think provide good signal, but in the end it's just a bunch of trivia. Sounds like you ran into one of those, based on the "what is 2^9" question. I used to work with a graphics programmer who'd always ask the candidate to write out the formula for doing a vector cross-product from memory. I argued that it was a pointless test; it's really easy to get wrong and most people use a library for that calculation - it was more useful to test if a graphics-oriented candidate understood what a cross-product was for. But he was adamant that people should know this kind of stuff from memory, with no justification as to why.
|
|
#
¿
Aug 3, 2023 20:32
|
|
|
Some thoughts - don't waste time on someone who isn't going to change. Invest in them for some period of time, but if you're not getting any return on that investment, don't throw good money after bad. - learned helplessness. Had a team member who would immediately consult others whenever they encountered a problem. Didn't read error messages which clearly suggested the solution, didn't even try. And because the others liked helping out (feeling useful, a chance to take a break from their own boring tasks, whatever), this person never learned to figure things out for themselves. Don't let this happen to you. (although it doesn't quite sound like it's that kind of situation) - learn "non-violent communication" to communicate what you want them to do in the future. In essence, "I notice you <thing they do>. This makes me feel <negative feeling>. In future, I would like you to <rectifying behavior>". Something like "I notice that you submit PRs to me that have no tests, and clearly haven't even been tested. This makes me feel like you're not respecting my valuable time, and like you're exploiting me to fix it all up for you. In the future, I need you to ensure that all PRs you submit must contain a basic passing test suite. I will not look at them if they don't." NVC can be an important soft skill to learn, because it helps side-step certain types of disagreements. By making it clear what emotional needs of yours are not being met (disrespecting your time, feeling exploited, etc), it's not possible for them to counter that: they can't deny your feelings, and it cuts to the chase of why they need to change their behavior. The other way to side-step disagreements is to have team coding standards that everyone has agreed to in advance. Like "all PRs must have a clear description and link to a ticket", "all PRs must have a passing test suite", or "all Python files must be formatted with Python Black"; you don't have to be the bad guy, you can just deflect by pointing to the standard.
|
|
#
¿
Oct 20, 2023 00:05
|
|
|
Paolomania posted:I thought the whole point of SWE carrying the pager instead of ops was to motivate fixing stuff. In practice, the SWEs weren't knowledgable enough on SRE matters to fix that stuff, and they didn't want to invest learning, so whenever an emergency happened they'd just loop in an SRE who could mitigate the problem quickly. I saw the primary value of DevOps was that Dev got better empathy for Ops's job, and accordingly designed their software to fail less (better tests and higher quality code, don't YOLO deployments), and fail better (more useful logs, fallbacks, avoid cascading failures, etc). It did not result in less on-call for the SREs because all Devs got added to the on-call rota.
|
|
#
¿
Nov 2, 2023 06:15
|
|
|
Falcon2001 posted:we have this very clear social rule that 'if you found it, you have to solve it'. quote:I seem to be the only one that's actually digging up these issues instead of burying them. This is definitely a management issue. People should feel psychologically safe to submit issues about problem areas without fear that it'll get ignored or they'll get "penalized" by having it immediately assigned to them. And if the team is constantly in "running around with hair on fire" mode all the time, then this might be one of the reasons why. Management should be identifying "force multiplier" opportunities like this, e.g. "Fixing this flakey monitoring is a force multiplier because less false positives to deal with means we now have more time to spend on other issues."
|
|
#
¿
Nov 20, 2023 18:52
|
|
|
Edly posted:Solving problems together - if you have a team of 5, don't have 5 projects in flight with everyone working off in their own corner. We follow a "no 1-person projects" rule and it's been effective. I would love to institute a rule like this but my team is spread across many countries/timezones so it's been really hard to get people to work together in person consistently. People don't seem to like self-organizing; I have to constantly push them to setup meetings to collaborate with each other, it's exhausting.
|
|
#
¿
Mar 6, 2024 21:21
|
|
|
I've known 2 people who worked for Netflix, and they both said that Netflix pays very well but expects you to bring your A game at all times, and the second that drops to A- they will tip you out the door.
|
|
#
¿
Apr 13, 2024 18:16
|
|
|
|
| # ¿ May 13, 2024 08:26 |
|
|
Quitting is perhaps a permanent solution to a temporary problem. You may like your management but I'm not getting the feeling they're doing a great job on this. Ultimately they're responsible for the success of this project, and from what you've said, it sounds like they've put it at great risk by letting you become the single point of failure. My other observation as an ex-FAANG SRE is that it never occurred to me before I joined that they'd expect everyone to not only be technically skilled (that's all they tested in those infamous interviews after all), but also competent project managers and communicators. Prior to working there, I was simply told what to do, and periodically give status reports. But at the FAANG, all of a sudden I was responsible for what I chose to work on, planning & prioritizing features, driving its progress, communicating its status to stakeholders, lobbying for resources, etc. And as a former code-monkey, I didn't have great skills in those areas. It was "learn or perish", and while I learned a lot, ultimately I perished. I put the blame on myself until much later when I realized the full extent to how they'd overloaded me. I'd taken it on without question because I'd bought into the propaganda that everyone who worked there was super-smart and capable, and I was hired there, so therefore I must be of the same caliber. But it simply wasn't true. I may be projecting a little here, but my feeling is that you're in a similar situation. You've been burdened with the task of project management, you feel responsible for this project's success, and now that it's at risk (and not for reasons entirely within your control), you feel stressed out enough to consider quitting. I think there are 2 important questions to ask yourself: 1. Do I actually want all this project management / tech lead work? Or would I be happier with less responsibilities, more coding? 2. How do I make this role "boring"? Meaning, how do I change my attitude so that I'm not stressed out about this project? The various project managers I've encountered don't seem to get stressed about their projects. I suspect they achieve this by being detached: they care about the process, rather than the outcome. A good project manager cat-herds people, ensures items are planned & prioritized, risks are assessed, and status is communicated... but they're not emotionally invested in the project itself being successful. Consequently, they only need to focus on whether they're doing their job well, and not whether the project will actually succeed, or stress about the inevitable poo poo That Happens that might delay delivery. When these invariably happen (e.g. "we don't have enough people / time / skills to complete this by the deadline!"), they calmly just identify that as a risk, perhaps come up with some mitigation ideas, and communicate it up to management... it's not their problem to own. It sounds to me like you are both emotionally invested in this project's success, and consider the risk of failure to be your problem. And imho, neither of those should be the case.
|
|
#
¿
Apr 30, 2024 06:50
|
|