571–580 of 704 posts
That guy is not a developer and if he is he's not talented.
I would never hire someone like him. Pure waste of time reading this.
Earlier quoted context omitted.
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.
> I'm pretty sure an overarching focus on task realism fixes most interviewing woes, including this one. 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.
Earlier quoted context omitted.
I don't understand splitting an API into a bunch of "microservices" for scaling purposes. If all of the services are engaged for every request, they're not really scaled independently. You're just geographically isolating your code. It's still tightly coupled but now it has to communicate over http. Applications designed this way are flaming piles of garbage.
The idea is that you can scale different parts of the system at different rates to deal with bottlenecks. With a monolith, you have to deploy more instances of the entire monolith to scale it, and that’s if the monolith even allows for that approach. If you take the high load parts and factor them out into a scalable microservice, you can leave the rest of the system alone while scaling only the bottlenecks. All of t…
That's a common argument for microservices and one that I always thought was bunk.
What does that even mean? You have a piece of software that provides ten functions, running 100 instances of it in infeasible but running 100 of one, 50 of three and 10 of six is somehow not a problem?
That must be really the perfect margin call of some vsz hungry monstrosity. While not an impossible situation in theory, surely it can't be very common.
There are plenty of reasons to split an application but that seems unlikely at best.
I predict the following changes: 1) Typed languages are worse, and you want people with high levels of competence. 2) Java actually IS terrible. You win very little by designing for incompetent coworkers. Plan for competence, and hire appropriately. Small elite teams beat large incompetent teams every time. See #1. 3) Thinking through scalability upfront matters in many systems. Not all systems. Many systems. 4) SOLI…
Typed languages can be better utilized for self documenting codebase. The types are used to show clear intent for the code.
- Good architecture beats good code.
- There are things I can express in dynamic languages which are hard to express in static languages.
- If you're not expressing those things, typed static languages win.
- When you're contorting your architecture to fit into static languages, dynamic ones win.
- Of course, if you don't have experience with dynamic programming, you won't think to express certain things or structure code certain ways.
There are, of course, academic languages which do both well (including optional static type systems for Lisp), but I'm not aware of any in widespread industry use (with an ecoystem of libraries, documentation, etc.).
Earlier quoted context omitted.
I would suggest the difference is if you feel pressure about your response. Is it ok to pass, or say something like "still working on same issue I discussed a couple of days ago"? If not, it's less like a casual conversation, and more like justifying your time.
I would say that's perfectly okay, but not for the reason you think. If your status is "still working on the same issue", your team should respond with "how can we help?". If your status doesn't change, that's a sign that something's wrong at some level, whether it's because you're stalled or because the issue was poorly scoped or poorly defined.
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.
But that would require me interrupting one or more people in the middle of whatever they are doing and possibly ruining their flow. Unless there is a very tight deadline, work on something else and bring up your blocker when you know the relevant people have time to listen.
That guy is a fruitcake. Pencil and paper are the best tools? I don't need other tools than my fingers, a keyboard and the IDE and sometimes a search engine they delivers relevant results. That guy is not a developer and if he is he's not talented. I would never hire someone like him. Pure waste of time reading this.
Anyway, if you're not using a pen and paper you're either really smart or you're solving easy problems.
Earlier quoted context omitted.
Refactoring is quadratically more difficult if you don't have tests.
Not this simple. Refactoring might mean invariance, but the more comprehensive your tests are, the more they also test the moving parts. That means, they have to be changed too. Many people forget the maintenance costs (and this has a much broader meaning than the refactoring example). Tests themselves have to be considered as a software (or more general) artifact with a cost.
We write almost entirely integration tests (and lots of them) and we rarely need to maintain tests since they're only tied to the UI. Most refactors happen w/ no test changes at all. Occasionally a UI change causes a big find/replace across lots of tests.
The tests are also probably less comprehensive than a suite of finer grained tests would be. Most tests tend to cover happy path and few edge cases.
When we started there were zero tests and refactoring was too risky so the early code decisions largely had to follow the architecture that was already present (which wasn't always what we wanted). As we filled out the tests for existing behavior we could refactor more.
I think the mostly-integration-testing approach led us to a pretty good balance by only coupling the test to the UI (with its own cons of course).
> People who stress over code style, linting rules, or other minutia are insane weirdos He seem to have not seen messed up code written and changed by a dozen programmers over the course of years with various notions about indenting, placing parentheses and comments and whatnot. I‘ve seen code with tabs and spaces mixed, wrongly indented code where following the logic is hard, code with no comments at all or code wit…
I guess it could be different in languages where style is more of a matter of personal opinion.
Usually i disagree with these types of lists, but this one seems pretty spot on. My only quible would be that only code quality static analysis is useful. Security static analysis on the other hand (e.g. taint analysis to find security bugs like XSS) is pretty overrated most of the time unless you work really hard to make it fit in your context. I also think linting rules are important, not for what they actually do,…
For the project I'm currently working on, the customer mandates that we must use SonarQube, Fortify and Nexus IQ. Not once has any of them found any kind of security issue. In fact every single thing they have raised has been a false positive, or just plain time wasting (e.g. forcing some arbitrary level of branch coverage). Also, they can be so slow - more time is spent in the build pipeline on these tools than is s…