> My point is that I rarely don't regret (for my careers sake) jumping in and delivering (obvious to me heh heh) value right away because I see the code I see where it ought to be and the new boss is really eager to see somethin, but I'm steamrolling toes and throwing elbows in eyes that I was entirely unaware of. I guarantee the people you will work with do not see you as a senior for some time, any misstep is a case against your status,
This is the best advice. And truly senior level people have been around long enough to see a lot of mid-level "senior" developers shoot themselves in the foot. I've also been on a lot of projects where bad practices aren't so bad because the team has strengths in other areas, and also best practices which collapse because the team has other deficiencies holding them back.
From my perspective simple boolean means a single known value stored in one variable. I suspect the underlying code performs a number of calculations for each one of the flow chart "booleans". Of course, maybe that points to a design flaw and there should be a single policy instance that aggregates all of the variables into one place.
If AI makes junior developers "better" than senior developers then what stops senior developers from adopting the tools and becoming once again better than the juniors?
> Coverage as a whole I think is useful only if you have an engineering organization that doesn't see the point in tests - which is going to be its own uphill battle.
I think coverage stats are always useful as they help find the edge cases that people forgot to test. A common culprit I've seen is error handling code where a bunch of tests target the happy path, but nothing tests the error logging when something breaks.
I think it's a more important feature than just a cosmetic color. Imagine if you bought a truck to haul cargo, but were then told it can only transport one type of cargo at a time. That would suck.
> it's connected to wifi (and it just happily connects even if it's been off for a month or two), and all devices can just connect to it and print. Never need to reconnect or do anything with it. It's a printer that prints. I love it.
Wifi is the only "innovation" that I cared about when buying a new printer. My old Brother just had USB, which was fine for 12 years. But my newer (10 years old) Brother has wifi and printing from the couch is great!
I sort of agree. Jobs usually have aspects that seem unrewarding. But if you spend most of your time cleaning break rooms then it doesn't let you grow the type of skills needed to land a SWE salary at the next place.
I agree Steam games are a difficult market to break into, but there are other ways to make money. Unity is also a nice platform if you want to produce interactive content for corporate or educational consulting projects.
Also consider the large number of places such as Hobby Lobby, Williams-Sonoma, or Home Depot that cater to hobbyist/amateurs rather than industry professionals.
> Abstract concepts map very well to objects. The problem of mapping a business domain to computing structures isn't unique to OOP.
Yes, I agree in theory. What I meant to say is that many concepts don't map to physical objects.
> In this case, I'm slightly gobsmacked that no-one pointed out that an employee is not their job. The contract of employment is a separate domain concept.
This is what I mean by flamewars. Your solution sounds good, but there are other people on this same thread still arguing that it makes perfect sense for an employee to fire itself.
I think OOP is great, but one weakness is that a lot of abstract concepts don't really map to objects. And then people have flamewars about where to put those concepts.
In the real world most employees would never fire themselves and HR would update things like payroll which the employee isn't allowed to change. Your example makes more sense as a justification for keeping a service layer.
Thanks for sharing that. It's mind-blowing that Google runs everything from a single repo. Most places that I work with create several repos for just one project.
Seems like a form of thought policing which didn't apply to yourself. Hyperbole that I trashed his career and "not a good look" also appears like an off topic attack.
Point is that `squash` is a useful tool used by many other successful professionals. I'm allowed to disagree with the author's opinion of the root cause of his bug and the factors that made it hard or easy to debug.
Seems like the real bug was in his handling of JwtSecurityTokenHandler.
He claims to be an expert on dependency injection with two decades of automated testing experience. I wonder what was so hard about writing a test to cover this scenario?
> If you're regular Joe (and, yes, that most likely includes YOU reading this) you can't afford to shut down most opportunities or you'll never get anywhere.
Anyone with software development skills gets tons of low quality app ideas from friends and family. And tons of other opportunities from recruiters paying below market.
It's hard walking away from a sort-of-ok opportunity when you don't have anything going on, but I've learned there are always more things coming up.
This is the best advice. And truly senior level people have been around long enough to see a lot of mid-level "senior" developers shoot themselves in the foot. I've also been on a lot of projects where bad practices aren't so bad because the team has strengths in other areas, and also best practices which collapse because the team has other deficiencies holding them back.