|
I'm convinced that most of the productivity benefits of pairing come about because you don't want to leave your partner hanging by taking a micro-break to check your email or sports scores or browse SA or whatever. So you end up actually working straight through, which is why it's both more productive and also feels more draining.
|
#
¿
Apr 17, 2016 09:09
|
|
|
|
| # ¿ Apr 27, 2024 07:31 |
|
|
If I'm running a bunch of code that was probably written under the assumption that environment constants aren't going to change underneath it, and I want to change or tweak some of those environment constants, shutting it down and restarting with the new values definitely seems like the way to go.
|
|
#
¿
Jun 12, 2019 06:12
|
|
|
Blinkz0rz posted:just to be clear, releasing a new version of a service is the pretty standard "bake ami, spin up new asg as canary, verify, then terminate old version's asg". If you've specifically engineered a part of your system to be configured without a restart, then sure, it can be okay to configure your running instances instead of starting new ones. That's only if you've specifically designed this part of your system to handle that, and hopefully you've comprehensively tested that it handles it correctly. It's not applicable for general properties that you haven't actually designed around being changed during execution. Having it automagically happen based on a change in the repo seems problematic too. If I were designing the system, I probably wouldn't do it that way.
|
|
#
¿
Jun 14, 2019 05:25
|
|
|
Blinkz0rz posted:yeah obviously the only properties we have as dynamic are the ones we've designed specifically to by dynamic. changes to properties are gated via code review. We typically use request flags. If the flag is set, it runs the new code for the new feature, otherwise it does the old thing. Your test code, qa process etc. can exercise that new code by setting the flag on their requests, but it doesn't immediately change anything when you roll it out to production. Once all the individual services are released, you can configure your user-facing frontend to start setting that flag on appropriate backend requests. You can even do a staged rollout while keeping an eye on your monitoring to make sure there's nothing unexpected going wrong. Finally, once the rollout is complete you clean up the request flag and make all the systems just do the new behaviour. I'm curious how you handle ensuring consistency with your system? It doesn't seem like you have anything that ensures a request will never hit a mix of services where some have the feature on and others have it off?
|
|
#
¿
Jun 15, 2019 03:55
|
|
|
I'm reading this:Pollyanna posted:Like I poo poo you not, we’ve lost at least half of the time we’ve set aside this week for a tech debt project because no one wants to review a tiny PR but I need to get at least two other people to look at it and yet no one cares and even if they did the change wouldn’t get deployed until Thursday and we’d only have one day to do the rest of the work we slotted for the week. And I'm thinking your process could use some serious improvement if you literally can't do step two until after step one is fully deployed. Can't you stand up a developer instance of the system, with your change included, and then proceed developing step two against that? We have a pretty global system where the people reviewing your changes could (in some cases) be in a completely different time zone from you, and working effectively in that environment means you need to be able to "work ahead" a little bit and develop later changes while your earlier ones are being reviewed. Jabor fucked around with this message at 05:09 on Aug 14, 2019 |
|
#
¿
Aug 14, 2019 05:06
|
|
|
Do you people not have threaded emails or something? I get an email for everything that happens to a change I sent out (or am a reviewer for), but it doesn't bury anything because all those updates end up in a single email thread.
|
|
#
¿
Aug 16, 2019 02:46
|
|
|
My Rhythmic Crotch posted:I have feelers out to get onto a different team as this is starting to get really tiresome. Everything I slam out for him is always on a quick-turn, gotta-have-it-now basis and it's getting so loving old. If he needed you to do something to finish his sprint items, that should have come up in sprint planning.
|
|
#
¿
Sep 13, 2019 04:11
|
|
|
PhantomOfTheCopier posted:Still seems weird to me that Google's hiring committees don't include the interviewers. It's an attempt to remove unconscious bias from the interview process, to try and be fair to everyone. Is your perception of a candidate influenced by their race, gender, and percieved socioeconomic class? Yes it is, and if you think you're above that then it probably actually influences you even more than it does other people. Nobody on the hiring committee knows any of that stuff, so the idea is that they can be more objective in their evaluation of the interview summaries.
|
|
#
¿
Oct 21, 2019 03:25
|
|
|
There's only a limited amount of time in an interview, and the interviewer is going to be mindful of how things are going throughout. Generally when I'm holding an interview I'll let the candidate keep iterating on their design until they're either finished, or I feel that further iteration is going to cut too much into the time needed for actual coding or further discussion. If you end up spending a significant amount of time on coding up a naive solution and then don't have enough time to code up the more interesting solution, you're not really putting your best foot forward.
|
|
#
¿
Oct 22, 2019 00:58
|
|
|
Generally in a hackathon you build a proof-of-concept, if people actually like it and the concept is proven then you get real time budgeted to make it actually happen. This could be integrating the hackathon code, or it could be rewriting the project entirely now that you're not making hacks and design compromises to go from zero to proof-of-concept in a few days.
|
|
#
¿
Oct 25, 2019 16:47
|
|
|
Carbon dioxide posted:As an example of what I mean, consider ScalaBridge. It's a worldwide volunteer organisation that teaches programming (using a Scala course) to underrepresented groups in software development for free, to give them a chance to enter the market and increase diversity in the field. ScalaBridge isn't the only Bridge organisation, there's ones for Ruby, Clojure, Go, Elixir, Elm, and Rust as well. They all teach underrepresented people programming in their own favorite language. But there aren't any Bridges for Java or C# or Python. I really believe this is because the people doing Java etc. aren't as dedicated to programming in general, simply because it's too common of a language. Holy poo poo this is funny.
|
|
#
¿
Jan 19, 2020 23:56
|
|
|
If you don't think personal development is important you're going to be in the "bad programmer" (or perhaps the "crusty dude stuck maintaining some legacy system that nobody likes working with") bucket at some point. Personally I've found the feedback received from my peers to be really helpful, both in pointing out areas to improve and affirming stuff that I do well. While the best feedback comes from outside the formal systems, having a mechanism that prompts people to actually give their peers feedback is pretty useful to make that actually happen. Stack ranking can go to hell though.
|
|
#
¿
May 6, 2020 07:47
|
|
|
Neither of them is the key - or rather, the concept of a "key" is meaningless without any context around what the key actually means. You have a text string, and a numeric value. In some parts of your code, you may take a text string as input, and return the corresponding value, which would make the text the key in that particular context. In other parts of your code, you may take a numeric value and look for a matching text string, which would make the value the key. In yet more parts of your code, you might just take a collection of pairs and use it to populate a list of options, in which case neither is acting as the key. Not every pair is necessarily a key-value pair, sometimes it's just a pair. Even if your language provides Pairs (or Triples, or higher-dimensional Tuples), it's often still a good idea to create a new type to represent a specific combination of data (in this case, a selectable item in a dropdown). This allows you to give meaningful names to the individual pieces of data (instead of just "first" and "second" or whatever the default names are), and makes code a lot clearer to read. I might quibble with the name they've chosen a bit, but their overall approach seems fine.
|
|
#
¿
Jul 29, 2020 13:00
|
|
|
asur posted:I don't know your specific situation, but I don't see how there's not a divide when one person, or a set of founders, stands to make 10x to 50x+ more than anyone else. I've also never seen a successful boutique company where the owner(s) aren't raking in substantially more than anyone else. I'm sure there's some cases of this happening, but it seems to be far outside the norm. Including appreciation in already-granted stock doesn't make too much sense because that could just as easily be investment income from other sources. Or that could match your investment income, if you had that much to invest and foolishly wanted to put all those eggs in one basket. Otherwise you might as well note that Warren Buffet gets more money from your employer than you do despite not doing any work at all for them. If you only count newly-issued stock over the period you're looking at then you get a more meaningful comparison.
|
|
#
¿
Nov 13, 2020 06:41
|
|
|
asur posted:There's a very good argument that investors, or capital, do take a disproportionate amount for their contribution compared to labor. A founder is not different and it's absolutely loving ridiculous to say that there isn't a huge divide between a founder who owns 50+% of the company but pays themselves the same as an employee, or maybe even nothing. I don't see a huge difference between the boss making $XX in grants and salary and $XXX from previously-granted shares, vs. getting $XX in grants and salary and $XXX from a similar-sized investment in index funds. Similarly, I don't consider myself a rung below any colleagues who come from a trust fund background even though they're probably raking in way more investment income than I am. But perhaps that's a bit different in a startup world where the boss bought in with sweat equity rather than a financial investment and those shares aren't actually worth anything at all until after the business succeeds.
|
|
#
¿
Nov 13, 2020 09:16
|
|
|
We have end-to-end tests that pass reliably, to the point we use them to run performance benchmarks on every release. We're not really testing a whole lot of business logic though - just start the app, go through this flow, did you get to the end without crashing and see everything you expected to see? It doesn't replace QA.
|
|
#
¿
Feb 26, 2021 15:22
|
|
|
In my experience a lot of critique comes in the form of "have you thought about X case? If so please add it to the doc" or "what are your thoughts on <some alternative implementation>". The idea being to ensure the entire possible solution space has been explored, and to make sure all that stuff is documented so that someone looking up the original design two years from now (without being able to talk to the original author) can understand why things were done in a particular way. Straight-up second guessing the author of the design and telling them they're wrong would be pretty highly frowned upon, which seems like a big distinction between a helpful and a toxic design critique environment.
|
|
#
¿
Apr 5, 2021 02:04
|
|
|
Protocol7 posted:Have a project that we're trying to wrap up. For context, I work in utilities trying to help companies identify all kinds of insights on utility poles. Sounds like you should be asking (and getting in writing) what form they do want it in, instead of trying to discover it via putting a lot of effort into trying something to only then be told no.
|
|
#
¿
May 19, 2021 04:22
|
|
|
Volmarias posted:Just bear in mind you'll want to have an escape hatch of some kind, in case of linter bugs or legitimate, articulable reasons to not follow the guide in a particular place. Ideally this is by some marker in the source code (such as a // NOLINT comment or similar), so that - it doesn't end up failing for the next person to edit that bit of code - if the same exception happens a lot, you're motivated to fix the linter so that you can get rid of those ugly comments
|
|
#
¿
May 31, 2021 03:28
|
|
|
Documentation only gets written when the organization tangibly values documentation. I by "tangibly values" I mean "spending a bunch of time writing docs instead of code will be rewarded when performance evaluations happen". If writing docs is negative for your career (compared to your peers that spend that time writing code instead), then docs will not get written.
|
|
#
¿
Jan 15, 2022 15:09
|
|
|
You can navigate immediately to the part of the code that's probably causing your bug, just by looking for the flying V.
|
|
#
¿
Feb 11, 2022 05:37
|
|
|
I would be looking into an automated script that adds the accessibility checks instead of doing it manually component-by-component. If any of them don't pass the accessibility checks, add them, disable them, make them the problem of the team that owns that component. I assume you have a mandate of some kind to add all these rather than doing it on your own initiative, so leverage that if you need to. Especially if you're eyeing a senior position, where automating things to accomplish them more effectively instead of doing a bunch of toil is just expected.
|
|
#
¿
Mar 20, 2022 23:54
|
|
|
You can just make a separate window. You know, exactly like you would if you had it in its own off-label instance of Chrome, but you still have all the features like being able to make more tabs.
|
|
#
¿
Apr 5, 2022 03:04
|
|
|
That seems pretty reasonable for a general rollout. But I would expect a limited/canary rollout a bit before then, and letting it soak in canary for long enough to make sure there are no issues is one of the reasons it would take six months. I'd also expect them to be accommodating if you had a business reason (that's not just "I must have the newest shiny") to be on the latest release sooner than that.
|
|
#
¿
May 19, 2022 13:22
|
|
|
My design process is: - understand the system - understand your goals - do whatever feels right - solicit opinions from other people to validate what your gut told you and see if there's anything you missed about the problem space Which is really hard to teach, because it comes down to having a good instinct for good design, so that good designs "feel right" while bad designs have you feeling that something's off somehow. Does your team as a whole share design docs with each other before working on projects? If so I'd recommend reading your coworkers' designs - are they how you'd go about solving that problem? If not, why did they choose this way rather than your way? Is there a concrete advantage to their way or just a difference of opinion? If you have historical designs available, then it's also worth looking through the designs for the shittiest part of your codebase that everyone hates having to work on. Is the pain you currently experience an inevitable outcome of those designs? If you saw a new design that was going down the same road, would you recognize it and be able to push back on it? The most important part of design sense is experience, but you can accelerate gaining that experience by making the most of the lessons that you're presented with.
|
|
#
¿
May 27, 2022 07:28
|
|
|
brand engager posted:I don't know what a design doc looks like. What they want us to do is come up with and explain a design on the open issue, and then have someone else review that design. A "design doc" is just a document explaining a design. If you're making something new, a typical design doc will open with the problem you're trying to solve, any relevant context that puts constraints on your possible solutions, and the design you intend to go for. Frequently your design doc will also have alternative designs that could have been used, and reasons why your preferred design was chosen. Also frequently your design doc will start with a bunch of possible designs along with their positive and negative aspects, and actually choosing which design to use is done as part of a discussion with the team. I would recommend writing these sort of docs - not only are they a good way of soliciting input and review from your coworkers the way your boss wants you to, just the act of writing down all the stuff you're thinking about helps you really understand the problem you're tackling and the design you plan to build. Often in the process of writing down your design you'll identify issues that would otherwise have only surfaced after you'd spent days or weeks trying to implement it.
|
|
#
¿
May 27, 2022 16:53
|
|
|
One story per screen probably doesn't make a ton of sense. - Most tasks users will actually want to do will require more than one screen - Most screens will be useful for more than a single task
|
|
#
¿
May 31, 2022 16:40
|
|
|
Is your codebase actually so large that it would be a problem if everyone just checked out all the code and always pulled down the latest changes to everything? Is it going to grow to a size where it will become a problem in the next year? Because if not, you don't really need a "monorepo package" at all - fundamentally you can just stick your different projects in different folders in the same repository and it will work for you. Anything you want to layer on top of that (like shared build caching) is an optional extra that you can do if you think it will add sufficient value to justify the time you spend on it.
|
|
#
¿
Jul 7, 2022 17:22
|
|
|
If this is a one-person gig then stuffing everything in one repo is just the obvious way to go. The scalability issues that people have with monorepos will just not be a problem for you at all. Splitting into multiple repositories is the thing you do when you grow too big for a single repo to work easily, but are not big enough that you want to devote people to making a monorepo scale.
|
|
#
¿
Jul 8, 2022 05:17
|
|
|
It sounds like he wants audit logs. And yeah, if your mechanism for getting audit logs is "reconstruct the prior state of the system and work out what it should have done assuming everything worked correctly" then that's laughable, but the authority pointing out that it's wrong shouldn't come from a system design book, it should come from the thing that these audit logs are intended to be used for. It may be that he doesn't know he wants audit logs, he just knows he observed logging like this at some old job and thinks setting up something similar here shows initiative.
|
|
#
¿
Jul 28, 2022 07:54
|
|
|
As a concrete example, let's suppose you have a Users table and a File table, and Users can upload Files. It might seem like your data is interrelated, because your File table has a foreign key to the Users table indicating who uploaded it, but is it really? When you request information about a File, do any of those queries actually want to join against the Users table and grab things like the uploader's hashed+salted password? It might make sense to pull a lot of that User information into a separate database, that is only ever accessed by your authentication service. Once you've done that, you can consider also moving stuff like the user's display name and profile picture to your User database, and have your File-displaying code look up that user information via a purpose-built user information API rather than doing a database join to include it in their File results.
|
|
#
¿
Aug 7, 2022 06:54
|
|
|
prom candy posted:Got it, thanks! What happens when the PM says we need to add search to the file list and it should match against the user name? I guess that's when you cache a bunch of denormalized data in ElasticSearch or Algolia? If that's what you'd do in the original structure then yeah, you could keep doing that. An alternative would be to just separately search the files and the users and then merge the results before you present them back. (This also helps you do things like not only show results from people named June when someone searches for "June Sales Report", which can help make your searching more useful).
|
|
#
¿
Aug 7, 2022 14:57
|
|
|
If this is for sprint planning, the useful thing to estimate is most likely to be "when will I be freed up from this task so I can commit to something else". If your QA and release process requires constant babying by the feature developer to push things through, and you won't be able to pick anything else up until after it's done, then you should include that time. (Really you should fix your process to involve less bureaucratic makework, but let's suppose that's off the table for now). If it's a more hands-off process where you can send it to QA, spend five minutes next week pushing the "yes release it" button once QA signs off, and otherwise not worry about it at all once you've handed it over, then you should just include the actual feature building time.
|
|
#
¿
Aug 10, 2022 03:41
|
|
|
New Yorp New Yorp posted:But if QA is the bottleneck -- and it always is anytime there's explicit manual QA -- then you're just releasing more work to get held up at the bottleneck. Again, this depends on who the estimates are for. If this is for planning your own sprints, then your own time is what's relevant to that planning. Are you going to sit around twiddling your thumbs for the second half of the sprint because you finished your part of it and are waiting on QA? And for what it's worth, we do QA on all our releases and major features and QA resources have never been "the bottleneck" for us - they're a step in the process that takes a pretty consistent amount of time. If a lack of inexpensive QA resources is bottlenecking your expensive developer resources, then whoever's in charge of your staffing is an idiot.
|
|
#
¿
Aug 10, 2022 04:35
|
|
|
what? i'm talking about the sprints that you as a team of engineers are doing in order to deliver on engineering goals. the estimates that matter for those sprints are the engineering work that will be required from your team. work that will not be carried out by an engineer on your team does not factor in to what your team can accomplish during the sprint, and should not be part of your estimate. these are different from product-focused estimates like "a major customer wants this feature, what estimated ship date should we give them" which of course should include everything in the path to get that feature fully shipped.
|
|
#
¿
Aug 10, 2022 18:58
|
|
|
We have a hook set up in code review that looks for specially formatted comments that say "hey if you change anything in this block, make sure you change this other block in this other file too", and flags your pull request if you changed one but not the other.
|
|
#
¿
Sep 2, 2022 02:05
|
|
|
Pay a competitive salary in addition to good benefits. I know you say you have "competitive compensation", but the fact that you're getting outbid by enough that already-hired folks are consistently jumping ship for higher pay suggests that that's not entirely true, or even if it's competitive in the local market it's not competitive with remote positions from companies in high-paying markets.
|
|
#
¿
Sep 22, 2022 04:31
|
|
|
Ytlaya posted:But one major feature was recently separated out into its own command line application that I had zero role in developing and don't know how to update outside of creating a new guix profile, so I can't just go in and find/fix the issue myself (and I also have zero clue what the issue is, because the application just isn't returning anything). There's some odd passive voice here. Who did the separation? Are you allowed to talk to the person who wrote this application and is responsible for maintaining it?
|
|
#
¿
Nov 22, 2022 23:44
|
|
|
worms butthole guy posted:Dies this advice ever leave to anything other than them terminating you the first chance they get for poor work ethic In the tech industry, any place that'd can you for that is a place you want to be moving on from ASAP anyway. YMMV in other industries that treat workers as replaceable cogs industry-wide.
|
|
#
¿
Dec 1, 2022 23:46
|
|
|
|
| # ¿ Apr 27, 2024 07:31 |
|
|
Knowing the git CLI is a status signal because you can't actually use the git CLI even remotely effectively unless you understand the underlying model. You can totally muddle through committing changes and pulling down fresh ones in the GUI (as long as you stay on the happy path) without any idea what you're actually doing. Therefore, anyone who knows the git CLI probably knows how to actually use git well, while anyone who doesn't is an unknown quantity, and may well do stupid poo poo like reverting two week's worth of everyone else's changes because they clicked the wrong button by accident and didn't even notice that they'd hosed it up.
|
|
#
¿
Feb 21, 2023 10:43
|
|