501–510 of 704 posts
> Typed languages are better when you're working on a team of people with various experience levels I would extend this to say that a test suite, static analysis, linting, code formatting and a ci setup are more and more important, the bigger your team is.
>>> Typed languages are better when you're working on a team of people with various experience levels I picked up the opposite qualm after working in a multi million line codebase in python, that goes back almost 2 decades in a large bank. Dynamically typed languages actually work, at all scale. Statically typed languages are good for simple types (int/string) but they're catastrophic for complex types (dict, map, da…
With a language like python, you spend a tiny bit less time typing out types in the source code, but that savings is totally eclipsed by the extra time you need to spend reading through documentation and source files to make up for the information which is missing from function signatures, and the time you spend chasing down bugs at runtime.
Earlier quoted context omitted.
> If a good developer you know, recommends someone they worked with: It's almost an instant hire. But for the rest, yeah, it's incredibly tough. A talk I watched recently by Ijeoma Oluo made a point I had never considered before: statistically, most people refer friends, and most friends are of a similar background, race, culture, gender, etc. It's not intentional- people aren't going out of their way to only refer p…
What is the upside of a higly diversified worksforce? Where I work we're all white males age 20-60 except accounting, they're white females around age 30. What's bad about this? What value does it bring to diversify, what should we look for and why is it important? Or are we too small to need diversifying yet with only about 30 employees?
If your company is providing services to specifically white men and women in the 20 to 60 age group, you have a pretty good mix of people. You could use somebody who isn't in the target demographic like most of you to help you out of the demographic Johari window, but otherwise your diversity is perfect.
If you're trying to market to people who need food around the world, you will at some point hit a wall on how much you can understand all the different markets. For instance, what do a bunch of white guys from the suburbs know about how a Sub-Saharan African interacts with food markets?
Earlier quoted context omitted.
Agree with this wholeheartedly. Standups are annoying but I have learned they are necessary, even as a very experienced developer. Sometimes things just cone up you wouldn’t otherwise know about and it encourages helpful, meaningful communication amongst the team. What’s not helpful is when standups are treated like status reports. That’s not the purpose - even uber green newbies are responsible enough to do their wo…
I do not understand why people have to wait to discuss the blockers? Discuss a blocker whenever you have one.
Of course you're right, you should discuss blockers whenever you have one. But people don't want to discuss blockers (or don't want to discuss at all), or don't identify something as a blocker, or would like to solve it themselves, or want to "protect the team" from this information, or think they'll get it resolved sooner without extra communication, or expect that they'll disagree on the course of action, or feel ashamed of having this blocker, or any other reason out of a hundred.
They won't rationally formulate it like I did just above, but it's just what people do: they get biased and their brain doesn't take the most rational course of action. A personal bias: I tend to prefer solving uncertainties by writing more code than talking to people. This is a stupid thing to do and I actively fight against it, but the fact is that I naturally tend to favour the "code" approach to the "communication" approach: standup forces to surface the problem and people can challenge me.
Earlier quoted context omitted.
> Individually, we as interviewers can shift our mindset towards looking for strengths instead of weaknesses, accommodate different backgrounds Virtually each time I've been interviewed myself the attitude was not to find out what my strengths are, but to discover gaps in my knoledge and skills. I think that's the standard in our industry. Sadly, this is exactly the oposite of what companies should be looking for. Th…
I'm pretty sure an overarching focus on task realism fixes most interviewing woes, including this one. There's a cultural obsession in this industry with testing things that supposedly correlate (usually poorly) with ability to do the tasks we actually want people to do and not the actual task itself. I think it's probably rooted in goocargle culting.
This can turn out pretty badly too. I was rejected by a company, apparently because I couldn't figure out the solutions to some problems they've been struggling with for years. I tried to guess, but either I didn't have enough context, or simply they didn't like my suggestions. The whole thing was very odd.
I'm not one, but my money is on this one changing, at least in tone. It's deliciously ironic as currently written.
Almost 20 years of professional experience here: I fully agree with this list. I even want to add a few things: > Clever code isn't usually good code. Clarity trumps all other concerns. My measurement is "simple and clean" code. Is it simple and clean? No? make it so! > After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. If a good developer you…
> If a good developer you know, recommends someone they worked with: It's almost an instant hire. But for the rest, yeah, it's incredibly tough. A talk I watched recently by Ijeoma Oluo made a point I had never considered before: statistically, most people refer friends, and most friends are of a similar background, race, culture, gender, etc. It's not intentional- people aren't going out of their way to only refer p…
The "early on" is important though, since "just try really hard" doesn't scale.
Earlier quoted context omitted.
I generally agree. But static analysis tools are still pretty dumb and sometimes cause extra work to no benefit. Flagging a method for cyclomatic complexity when it uses a case statement that is blatantly obvious and simple to any human seeing it, for example. Or just happening to notice a bunch of issues in file B when you commit file A but didn't even touch file B. Overall it's good, I like it, but with the caveat…
Cyclomatic complexity IMHO isn't a good metric for code complexity as understood by humans, but sometimes it can be insightful especially when it's unexpected. My favorite static analysis issues are the ones that flip-flop between two issues, I love doing "merge this if statement with the enclosing one" only to get "expressions should not be too complex" after I've merged them. As long as you have the power as the de…
And as long as we talk about tools that do some kind of semantic analysis (not just syntactic) on a turing-complete language they will always either have false positives, false negatives or both. Rice's theorem guarantees that.
They still can be useful though. I programmed a static analysis tool for PHP a long time ago and it worked surprisingly well.
Earlier quoted context omitted.
There are specific cases where a non SQL database is better. Chances are if you haven't hit problems you can't solve with an SQL database you should be using an SQL database. Postgres is amazing and free why would you use anything else.
People keep saying there are specific cases where NoSQL is better, but never what any of those cases are.
Earlier quoted context omitted.
Agreed. It’s a deliberate inefficiency to make sure you at least have a chance to communicate with your team on a regular basis. Otherwise you might go days or weeks without the chance to have a critical two minute conversation.
That sounds suspiciously like your team is not communicating enough in the first place though. I mean, I guess the profession does get its fair share of introverts, but I would have expected enough teamwork that everyone knows what everyone else is doing, at least roughly. At my last gig I remember we had three backenders and four frontenders on a game we were building and the stand-ups seemed superfluous, Ryan on th…