dosethree

Being old doesn't mean good. From my experience, using j2ee or spring to make a web app is grossly overcomplicated (I have heard of but not yet used spring boot). Asp.net is fine but anyone who is paying $$ for that is probably a dumbass

Why is this article getting upvotes? It says almost nothing, certainly very little interesting or actually useful

The best teams are T-Shaped (specialists who also generalize) that doesn't mean they are specialists in everything, but as a team they have the expertise they need collectively. Those teams work well because when someone is on vacation you can still execute as a team because you cross train. It's not rocket science here people

This article seems to totally go against my personal experience, that maintaining a suite of applications of varying languages in prod and dev is made a lot easier through containerization and standardizing on top of that. The same can be done with VMs but the container orchestrators (kube/etc) are usually closer to the level of abstraction the developers need (docker -> puppet)

Well thats probably something to do regardless

" It’s a myth that communication is hindered by private offices, as much as managers or PMs want us to believe otherwise."

I don't like open offices either but I don't know if you can throw that out there. Private offices offers a degree of separation (so does working from home) that will probably reduce certain types of both beneficial and nonbeneficial communication.

I just get regular reddit when I click that, did they turn it off?

I don't think calling an all stop would necessarily help. Usually people just ask for help at standups

Most jobs I've been at if you're the first new hire in a while you are going to experience something like this, and it's important that you spend a lot of time adding to the documentation to make it easier for the next new hire.

You can get what you want with capistrano and a something like unicorn taht supports no downtime deploys

The cost of technical debt is obviously much harder to quantify than the value of new features (though most companies don't even do that well), so most people don't try and that's why we end up constantly prioritizing features over paying down technical debt.

However, tasks that improve engineer productivity, like speeding up the test suite, or adding automated tests, removing unneeded code, a badly needed refactor on a critical piece of code can not only makes new features quicker to develop, but also makes the technical improvements quicker to develop. Features have the opposite effect.

I've worked on Kanban agile teams that don't do estimates, and I strongly prefer it.

I think it's still critical to demonstrate incremental value, but there's a deadline oriented culture at some places that just ends up hurting the business by causing people to make the wrong trade offs and short term thinking. Not so bad in some contexts, but terrible in others.

I think you might have the idea that "Quality" is some sort of nitpicking, ambiguous goal. At most places I've worked, it just means well thought out, tested, architected code that follows best practices.

Executes should have some rough sizing of large undertakings for making high level business decisions - I don't think that's what the author is referring to.

This comment is a reaction to lots of dysfunctions that I've personally observed at software companies that are highly deadline driven. Deadlines are often intended to drive focus and productivity but frequently have the opposite effect, and engineers often use them as an excuse to create problems we'll have to spend even more time to fix later.

You say it like it's a con, but this is what makes Apple unique compared to their competitors. The PC market will always be around to make a clunky laptop with a huge battery if the customers want it.

Apple keeps pushing the limits despite annoying some of their customer base. And often times, the bet pays off in the long term - but not always. In the case of battery life, the tech hasn't caught up enough to make it not a problem for customers yet. Example: I have a battery case on my phone that looks like crap.

I'm very interested in buying these and I have a headphone jack so I don't think it's purely a money thing, but obviously 159$ is quite expense (though so are most bluetooth earbuds that are likely not as nice as these in some ways)

for me, it's a bit of column and a bit of column b

I TDD a fair bit, and both kinds of tests are useful. I do really love the tests that I write to replicate a regression bug. The other types of tests are more like living documentation of my internal APIs for future developers, and are still useful.

Agree with some other comments here:

Good: Code review? Great. Boy scout rules enforced in legacy code? awesome. The QE analysis seems great!

Bad: Failure to expedite? Fail. And without that there's no story.

Also at a high level, the fact that it is only 1 line of code is irrelevant. It's not closely correlated to the riskiness of the change.

I re-read this later and wondering if that's actually true. Our industry is very "you don't have anything to do this weekend, right? right!" Anyways, it's true for me.

The problem with using calendars is actually you're pretty flexible about when you want to get most stuff done, you just have a deadline. But you don't want to do it at the last minute, so for a weekend task you want to check in a few times to see if you are not too busy to do it.

http://www.dueapp lets you put a time to be reminded and that has really clear snooze functionality. So I procrastinate a lot (snooze) but I'm always aware of it in case I have a deadline, and I don't have to worry about remember it.

(I'm unaffiliated with Due I just love the product)

Sounds good, but the vast majority of software eng does not require this, and i think it's just a different problem with a different solution then licensing

Most job seekers in our industry have jobs and lives outside of work