|
Lord Of Texas posted:If pull requests aren't being reviewed within a day, or more preferably within an hour or two, your company's culture is hosed and needs to change. Reviewers start, get interrupted after half an hour, then never bother to return because... What's the point of reviewing that mess?
|
#
¿
Aug 14, 2019 02:26
|
|
|
|
| # ¿ May 11, 2024 10:42 |
|
|
M31 posted:It's 2019,... I literally have a rule that filters all my mail to trash if I'm not in the To field and it's the best. 
|
|
#
¿
Aug 16, 2019 07:27
|
|
|
That Dang Lizard posted:I was always partial to the 'line in .bashrc that appends sleep 1 (or 0.1 depending on support and how sneaky you're feeling) to .bashrc' prank. code:
|
|
#
¿
Aug 20, 2019 22:41
|
|
|
Based on that description it sounds like patch will just be a server side get+post, because that's the only validation you'll be able to perform. Gee it would be nice to have a database with savepoints so you can lock+patch+validate+patch+validate+commit. Edit after the previous two posts magically appeared: How is updating a progress value going to fail the type of multi-field validation you mentioned before? What are you really trying to do? PhantomOfTheCopier fucked around with this message at 23:19 on Aug 21, 2019 |
|
#
¿
Aug 21, 2019 23:17
|
|
|
Progress ping API seems like a good place to start. Remember to code in a few spare sleep(100ms) statements so you can improve performance in the future when they keep complaining. "We found a threading bug in testing, this was the workaround".
|
|
#
¿
Aug 22, 2019 02:48
|
|
|
Just remember that a get/post can suffer race conditions, whereas patch presumably would prevent that. Content: Yes, the reason you are a software engineer is to uncover the complexities in the existing code. No, this does not grant you the right to file an 85% refactoring code review using the excuse "I kept finding that my small changes required bigger refactoring". One of the other reasons you are here is to take the complex and make the presentation simple.
|
|
#
¿
Aug 22, 2019 19:11
|
|
|
Munkeymon posted:I don't see how PATCH fixes that in the case of a related or overlapping change... EG, put(a=5,b=6) will happily overwrite anything, as in the above examples, but patch(a,from 4,to 5) can return a failure if something else has already changed a, after which the client can retry, refetch, etc.
|
|
#
¿
Aug 23, 2019 22:31
|
|
|
Won't bother quoting, but wth you've never heard of a lock? That would be the entire point of 'patch'. By all means convince yourself that you dislike locks and want to build a stateless, seamless eventually consistent API and data layer... but don't say you weren't warned. https://en.m.wikipedia.org/wiki/KISS_principle https://en.m.wikipedia.org/wiki/You_aren%27t_gonna_need_it
|
|
#
¿
Aug 27, 2019 01:12
|
|
|
My Rhythmic Crotch posted:I would love to use locks but I don't think I can sell that idea.
|
|
#
¿
Aug 27, 2019 22:45
|
|
|
That you can actually see light at the end of that train wreck... is enviable.
|
|
#
¿
Sep 4, 2019 22:30
|
|
|
Not sure why but lunch/hours chat makes me think I'm not compatible with my team. (Four paragraph write-up omitted, started off with...) I like to code so I show up early.
|
|
#
¿
Sep 10, 2019 00:04
|
|
|
6am to 2pm (or 7--3), and I eat two or three small meals during the day so I don't add an hour just for lunch. Most days my creativity has waned by 10am. I have serious doubts that the 1030/1100 arrivals who go out daily for their 60--90min lunch are sticking past 6pm, though I admittedly have never bothered to pay much attention to the timestamps on tool-generated email. People schedule 3pm design meetings. So late in the day, it's no wonder the designs suck.
|
|
#
¿
Sep 12, 2019 01:09
|
|
|
Naup, no kids here.graveportents posted:How do you pull yourself out of bed early enough to be in the office by 6am? 
|
|
#
¿
Sep 13, 2019 06:49
|
|
|
Rocko Bonaparte posted:God drat! Do you ever worry that you might get a cut some day and your blood won't clot due to all the caffeine? Maybe I should create an Ask/Tell.  (Note the post times, but I'm abed a bit early this week due to medical appointments.) Edit: My first question for graveportents was going to be, How much coffee are you drinking and when? PhantomOfTheCopier fucked around with this message at 13:30 on Sep 13, 2019 |
|
#
¿
Sep 13, 2019 13:15
|
|
|
Blinkz0rz posted:Why yes I do have a toddler at home and don't get much sleep, why do you ask 
|
|
#
¿
Sep 14, 2019 20:26
|
|
|
When not at work you want to avoid both physical and mental interruptions related to work. In the former case this means taking no work materials away from work, such as any paperwork or learning material. It also means reducing or removing communication, as previously mentioned, so that you can't be contacted after hours nor are you tempted to just "check your email while you're at the computer" or on your phone. The latter case is more difficult, particularly if you enjoy exercising your creativity at work and solving difficult problems. You may find yourself thinking about those problems when you're not at work. By itself, a flash of insight may not be much of an interruption, but you must develop a habit of writing a quick note for yourself and then moving back out of work mode very quickly. You cannot just "sit down for a few minutes to write down this code while I'm thinking about it" because invariably you'll still be there an hour later. If you have an idea that requires research, then send yourself the idea so you can research it when you show up for work the following day. During your commute you should also not be looking up things for work, reading things related to work, or fleshing out ideas so that you're ready when you get to work. Instead you should be reading for your own pleasure, about other things that interest you personally, or solving your own problems. I have a number of personal projects that require a great deal of creativity and mental effort, and in my free time I think about the next steps on those projects. In fact, I sometimes get flashes of insight about those projects while I'm at work. If you're part of an on-call rotation, then there are periods where it is impossible not to take work home. You want to understand your actual SLA if you get paged, so you can respond appropriately. In particular, you need to know which activities might be interrupted if you get paged, and whether or not you have to be ready for that. For example, if you need to take a shower do you need your pager with you? I still go running when I'm on call, but I need to have the pager with me; if I get paged I can get home fast enough. If I'm checking mail or taking out recyclables, I don't need the pager with me because I'll be back in three or four minutes anyway. Likewise, if I'm preparing a meal or something, I don't really need to constantly know whether or not I'm getting paged; as long as I notice in the next ten minutes it's fine. In some cases I'm worried about being able to reply fast enough, and then I make sure that the laptop is on and logged in so that I don't have to rush to do those steps if I do get paged. Of course I must ignore the temptation to do anything with the laptop unless I get paged.
|
|
#
¿
Sep 17, 2019 01:56
|
|
|
I need an SAcron app. I want to complain but if I do all my co-workers will immediately know I'm the goon. Let's just say people are making fairly bad decisions about refactoring code. Also,
|
|
#
¿
Sep 26, 2019 22:33
|
|
|
Cuntpunch posted:To answer my question, though, someone helpfully noted that Now That We Have Jira, We Can Do It! It sounds like they're firmly embedded in the mindset where "agile" means "focus on the loudest request and expect hourly adjustments to priorities based on a whim". Coupled with their demonstrated inability to create even basic milestones, you can be fairly confident that no project roadmap will ever appear. Don't let them find out about SaFe. This sounds like the type of company that defines process by fad.
|
|
#
¿
Oct 4, 2019 16:07
|
|
|
feedmegin posted:Literally. How is it SO BAD given what it's trying to do, it's not simulating nuclear bombs and poo poo "It was written for the Navy. That's why it keeps crashing." "Jira was used to plan the North Korean missile tests". "The Jira UI was based on the Therac 25". "Now we know what happened to Microsoft Vista".
|
|
#
¿
Oct 7, 2019 22:37
|
|
|
Yes it might be best to take the update at face value when it's given by the engineer that contributed 75% of the project over the last six months. Starting a project planning discussion when no one is available to perform the work is neither appropriate (in this unrelated meeting) nor efficient use of our time. Besides, if it was that simple to implement, why wasn't it done by any of the half dozen people during the project execution, when half of those were senior engineers? Ahha, you're volunteering to add it to your projects for the next four months?!
|
|
#
¿
Oct 9, 2019 23:16
|
|
|
Distributed CVS. Well it's no worse than the top of page suggestion 
|
|
#
¿
Oct 11, 2019 21:58
|
|
|
Keetron posted:Recently migrated a service from Java 11 to Kotlin, many days were like these. What helped is that I helped build it and the experimental Kotlin conversion in Intellij works pretty well. I'm looking forward to your stories of woe.
|
|
#
¿
Oct 14, 2019 22:52
|
|
|
Volmarias posted:2) If there's a particular style in your codebase about this and you aren't ready to push for change, just follow the style in the codebase Consider: On how many projects have you established style afresh at the beginning? Now then, how did you establish that? Right, you just copy/pasted it from somewhere else. Guess where they got it: Yes they copy pasted and bastardized it too. In any case, Pollyanna is lucky. My project is ready to release the first main component of three and, because a generally-disconnected manager happened to be walking through when I was explaining existing limitations, now gets to rollback months of standing design decisions. "Oh but we're going to do this" is not very aglie when that thing is months away, we have a vetted solution now, and it's consistent with the existing architecture. Just because you never did it is not enough justification to prevent us from doing it.
|
|
#
¿
Oct 16, 2019 22:54
|
|
|
lifg posted:https://youtu.be/r8RxkpUvxK0 "I've had candidates cry"! After 250 interviews I've not seen that. I guess this guy was still learning how to interview. I'll have to watch the remainder later (it's an hour presentation) but I'm consistently amazed by the anti-whiteboard sentiment. There are some outliers but every company makes it clear that is what will happen at an interview. Also if they didn't hire themselves... Had the company changed in the interim? A big company looks for different things year over year. "How do you put a number on that?" "You can't put a number on that". I think the ML people would disagree. Honestly, you know most teams really only need to ask a few key questions: Tabs versus spaces. Here are four code samples, which is the cleanest? Which editor/IDE do you loathe? What hours of the day do you want to work? Which software development methodology do you find most natural? It's like the modern equivalent of geekcode/queercode/purity tests.  ... PhantomOfTheCopier fucked around with this message at 02:39 on Oct 21, 2019 |
|
#
¿
Oct 21, 2019 02:30
|
|
|
Let's see how many of my technical interview questions have appeared online... 0/5 found so far. Regarding the brute force approach, I'd recommend you (as the candidate) provide the three-sentence summary version, note its performance issues, then ask if they'd like to see the code for that before moving onward to a better approach. The interviewer may have one or two questions just to clarify that you both have the same understanding of the solution, but most will know and expect that answer and will be all too happy to move past it to something more exciting. For coding interviews, yes you need to get some code on the board, but if you're targeting the 50-line solution in the given time you're doing it wrong. You also need to demonstrate good programming technique, which means helper functions, library calls, whatever. I'd rather see a complete algorithm that calls five helper functions, and then ask the candidate to code one of the helpers really well. That's solving the problem together with cleaner code and a chance to fully discuss program flow and data manipulation. I don't believe I've ever used a hypothetical question that has multiple parts. Instead the conversation starts by establishing reasonable expectations (limits) which can be broadened afterwards. "What if the customer really wanted support for feature X?" is a more realistic motivator than "Okay now solve it for n=4". I still see it a lot from interviewers using trivia/homework exercises though because there's little opportunity for extension. On the other hand, if some  asks you FizzBuzz, it's a good bet they want to see the code.
PhantomOfTheCopier fucked around with this message at 02:07 on Oct 23, 2019 |
|
#
¿
Oct 23, 2019 01:42
|
|
|
I've never had 10% time, even when I worked for AWS, but I've had plenty of managers and directors claiming they wanted their teams and orgs to make time for it. They followed one week later with 20% more work though, so it was clear they were just pandering. Yet another "what's good for Google is good for the world". The closest I saw was when the director announced it during a staff meeting. Everyone got excited and started their list of what to learn to boost their creativity. A week later we got an email about "approved projects for 10% time". Volmarias posted:That's what's meant by multiple parts, though. The classics being "now what if your grid is sparse and 1000 times larger" or "now let's say you cannot hold everything in memory at the same time" or "ok, let's say that this particular API call is both blocking and has high latency, is there a different way to do this that would work better for that case?"
|
|
#
¿
Oct 23, 2019 22:35
|
|
|
Queen Victorian posted:Hey guys, so I’ve been in my new job for a month and a half now and it’s going very well. People are cool, overall environment is positive and rewarding. It’s amazing how much better I am at things here now that I’m no longer being poo poo on all the time or feel like I’m being set up for failure every sprint. Second, I got a little misty because I realized that "I'm being poo poo on all the time and feel like I'm being set up for failure", which is one of the reasons I'll be taking part of my forthcoming day off to check the world of job openings. I don't claim to have anything quite as egregious as you, but my team is consistently playing this game of "we approve of all the design details... (work done)... we don't approve of what our packages require to ship those design details". Given that I don't see this with other code reviews, I'm starting to feel singled out. Yeah "if there's always a problem when you're around the problem is you", but in this case I think I'm just not the best person to support the team's passions at this time. Anyway it took multiple iterations to learn the right balance of "sticking with it" and "knowing when enough is enough". Glad that you've started a bit earlier learning that.
|
|
#
¿
Oct 24, 2019 23:16
|
|
|
How do hackathon teams' projects actually get included in production repositories? We have an open event coming up next month, but even with project proposals required a couple months before the event, I don't see even the working code getting included because it assumes the owning team can handle the increased maintenance costs. ("Shiny aluminum siding bro, but where's that going on my brick house?") Has anyone seen successful integration of hackathon code? Oh yes, the other problem with interview a la programming homework that I just witnessed a few days ago is scope limitations: Problem is so easy that you have ten spare minutes in the interview and no more code to discuss.
|
|
#
¿
Oct 25, 2019 10:55
|
|
|
Vulture Culture posted:If absolutely zero of those things are in your backlog already, are any of them important whatsoever? basically.
|
|
#
¿
Nov 5, 2019 05:21
|
|
|
I find myself in that rare but enviable position of finishing most of my daily work in a few hours and then just dinking with random improvements while waiting a day or two for answers from PMs and SMEs. Sadly even doing 5min of random stuff here and there when WFHing doesn't feel very productive, but I'm trying to keep my personal todo list organized to stay busy. The SMEs are usually the biggest source of frustration since they are perpetually confused, and most delays are because they don't know how to ask questions but want to micromanage. Lots of wasted time with code changes getting abandoned because they spent two weeks bikeshedding three lines of logic and then it couldn't be shipped because someone else did a feature change that caused a conflict. That means rewriting and an extra hour of testing. Wash rinse repeat. The most recent turned into a meeting because the solution has clearly become undebatable, but no one is quite sure what's in scope, the expectations, acceptance criteria, etc. Solution in search of a problem. Good job principal engineer.
|
|
#
¿
Jan 16, 2024 06:55
|
|
|
At least documents set some reasonable expectations, and deviations still happen but with relative to scheduled/approved work. For some reason our place is having serious beginning of year issues achieving anything, mostly because there are no clear statements for requests, and those writing the technical expectations are just as confused. Most tasks are complete, tested, and in review, and then everything gets thrown out and regresses back to an open task with more unknowns. Even simple refactoring is tying up leads and principals in knots, and some things are lingering because they're solutions in search of problems. Rambling, sorry. Anyway, I've been slowing down since every additional 24hr adds a 30% chance of regression, and that's less offensive when you haven't solved the problem four times already. Estimates, I completely disagree.  Estimates are typically easy, though of course they take practice like anything. Where they fail is any external dependency, particularly on people who can't estimate or have zero vested interest in the schedule. IE, work estimates can be very accurate; calendar estimates become more inaccurate with additional people or processes.People have delivered three-month projects for decades. The day over day slips probably have the same reasons in 2024 as they did in 24bce.
|
|
#
¿
Jan 20, 2024 08:22
|
|
|
 Lots of redundancy in these changes. Update the get+parse helper in this class to handle those common steps. (updates all instance functions to call a static helper that accepts the instance as a parameter, so it can call instance methods) Well that's rather creative!
|
|
#
¿
Feb 2, 2024 16:39
|
|
|
I last jumped 2yr ago and things have changed, but I searched Indeed and LinkedIn and directly checked those companies and applied. It's still probably best to steer clear of the LinkedIn recruiters until the point of desperation, or if you have a very niche role only filled through recruiters. Stick with 1pg unless you have specific academic or published works that support the role or compensation. I'd also recommend against embellishment even though it might reduce the number of replies; there's nothing that drops faster than the score of a candidate claiming experience with XYZ who can't even explain/demonstrate the basics. I am curious where the industry is with pre-interview process. Are companies using take home exercises, live coding phone interviews, entirely online gatekeeping (a la leetcode/hackerrank style questions and the dozen providers that appeared in 20-22)?
|
|
#
¿
Feb 14, 2024 06:59
|
|
|
I've interviewed candidates who bring their prepared answers. They are generally a bit scared, "Can I use my notes?". Sure! Why would I have an issue with someone who planned ahead? People can't remember everything; they usually have some examples they are really excited to share. It can also be very comfortable to get locked into one example instead of showing breadth of experience, and having the list helps. The trick is to know your strengths and weaknesses. Within reason you should be requesting allowances (I do not speak of legal accommodation) such as "Can I use my laptop to answer code questions?" or "Can you give me a 15min break between interviews?". A recruiter might ask why, so you should be ready to fess up. "No one can read my writing on a whiteboard" and "I get really nervous and want time to relax". If you get a jerk recruiter, so be it, but honestly most in the process understand all this and try to help candidates along. Why? You get better data when candidates aren't hiding under the table shivering in fear. And then there are jerk engineers who think an interview is about proving the candidate wrong and showing off their magnificence. 
|
|
#
¿
Feb 17, 2024 21:09
|
|
|
Judge Schnoopy posted:... One problem with engineers is not considering their audience. They'll post code for review with no background, no test cases, no commit messages distinguishing the feature from refactoring from cleanup from personal grievance. In the absence of listed expectations, your applicants need to both fully understand the application (to get a sense of flow, component priority, error handling) and then think about what could go wrong. Remember that candidates uncovering a fundamental flaw in an IRS tax calculation are the ones you want; not the people that only spot the misspelling on line five. Make sure you're measuring the right thing. Sit down and write your rubric. What's expected? What's required to get there? How long does each step take? 2x for interview stress.
|
|
#
¿
Feb 18, 2024 19:22
|
|
|
Volmarias posted:This is why some companies seem to be embracing automated tech screens more and more. If you're interviewing a few dozen candidates a week, then it's likely beneficial to have a fully automated online solution to filter candidates. Otherwise you'll benefit more from the hands on approach. I've still automated ours. 10min is enough for a quick code check, dropping in some input/output handler, and running 20-200 tests depending. We still check code and failures to ensure we know how they've screwed up, and for structure/comments/documentation/etc., but it's fairly streamlined.
|
|
#
¿
Feb 20, 2024 08:41
|
|
|
Cugel the Clever posted:I just cannot imagine doing, let alone proposing, LeetCode bullshit in 2024. Unless they've adapted to offer practical test scenarios instead of gimmick brain teasers, surely their poor correlation with on-the-job performance has been established for long enough that it should be common knowledge... Experience, even similar roles. https://hbr.org/2019/09/experience-doesnt-predict-a-new-hires-success Interview performance (well a little bit maybe). https://www.forbes.com/sites/quora/2013/06/28/is-there-a-link-between-job-interview-performance-and-job-performance/?sh=40424b1458bc What does correlate? Cognitive ability, but it's complicated. https://link.springer.com/article/10.1007/s10869-022-09796-1 Mental ability plus work sample, integrity test, or structured interview. https://psycnet.apa.org/buy/1998-10661-006 So I'd say: If you want to build a culture that isn't offended by leetcode style questions, use those. If you want a culture not offended by take home assignments, use those. Pair programming assessment, use those. Live debugging, timed debugging, GitHub existing candidate code review, whiteboard-only design, narfle the garthok, function duplication+extension, practical performance running on an ec2 instance, web app on their home server, live reading+documentation, test cases for existing code, security review... use whatever. Think of the choice you make as a basic filter leading to the more useful followup conversations.
|
|
#
¿
Feb 21, 2024 01:29
|
|
|
Ah the senior/principle engineers who are passionate about all code being unreadable unless it matches their personal style, have always been strong proponents of policy guides for style. After all, why shouldn't it take 15min or more to go through a four page checklist before typing code for discussion in chat?! They have also always been the last to improve the developers' lives with automation, even to the point of complaining that automation is not possible. But then... Did you know they conspire to make it so? Today's winner: Style that's dependent on context. After knowing the definition of the function, then you're allowed to determine the calling style. Because of the libraries, it actually ends up being runtime context dependent style. Yay!
|
|
#
¿
Feb 21, 2024 18:13
|
|
|
StumblyWumbly posted:I thought my team was the only one with someone against automation. 'Maybe it won't be perfect' is not a good reason continue doing dumb bullshit by hand Being the beginning of the year, a manager had it in their bucket list to just have engineers run the standard style tool and then let the interested parties put in whatever configuration they wanted. He presented that to them. Their response: We're not going through the configuration, there are a couple hundred options!
|
|
#
¿
Feb 21, 2024 23:59
|
|
|
|
| # ¿ May 11, 2024 10:42 |
|
|
Oh no you too? Yesterday (Wed) I watched a manager hop in a task and claim that, no, engaging a member of the Beijing team was not necessary to perform manual validation after a one-time scheduled script executes for an important customer tonight (Thu). Our Beijing team is generally engaged, engineers trade code reviews back and forth almost daily, and it will be 2pm their time (Fri) when the script runs. I have no idea how the manager is planning to address this today (Thu) because there's no opportunity to plan ahead with Beijing beyond just dropping it in their lap. Meanwhile the script runs tonight at 11pm, the local team obviously won't be around, and the company is closed Friday for a three day weekend because they decided to celebrate Employee Appreciation Day this year. I foresee a lengthy conversation with ggaanntt and calendar charts drawing little lines until they realize they have resources that can operate during standard business hours.
|
|
#
¿
Feb 29, 2024 16:26
|
|