mekane8

This was a well-written article, I appreciate the simple journalism on display. A reporter dedicating themselves to an area, showing up faithfully and reporting their observations without bias or personal commentary. What else could we ask for? I read it on the AP app and appreciated still having a source for this kind of thing.

Yes, that gels with what I was saying - use e2e tests for "big picture" assurance that the system is correct. Use unit tests for super fain grained assurance of individual business rules, etc. All of the legacy projects I've ever inherited have lacked unit tests, and are theoretically functioning correctly, so the e2e tests make sense there.

I graduated college in 2003 and I remember the excitement at good job prospects among my CS degree peers growing right along with the bubble. I remember being pretty depressed going into our last semester.

One of my favorite "historical" pieces from the era is "Mother Earth, Mother Board". https://www.wired.com/1996/12/ffglass/

Not specifically about the bubble, but lots of fun tidbits from the internet in those days.

I believe pretty strongly in the "testing pyramid" - that you should have a broad base of unit tests, with fewer integration tests and even fewer e2e tests. Source (also from Google): https://testing.googleblog.com/2015/04/just-say-no-to-more-e...

I think good unit test coverage is essential for good maintenance, but you can't cover _everything_ with unit tests. You definitely need integration and e2e tests to ensure bigger picture correctness. I have found that value one gets out of the different kinds of tests as you proceed up the pyramid get higher the closer to release you are, and are most valuable post release. During development they become obsolete too quickly due to changes in how things work. But locking in an already-released version to avoid regressions is great.

I personally like and get value out of stubs and mocks in my unit tests, but I think they suffer some of the same issues as code without tests - it's hard to know the original intent and it's hard to constrain later contributors into doing the correct thing. I can mock up an external part of the system for my unit tests and be confident I'm only testing the behavior in my module, but someone who comes along later won't have the same picture in their head and will come to different assumptions. Integration tests are definitely the way to go here, when you are wanting to ensure your unit works correctly in conjunction with external systems. But that doesn't make the unit tests bad, just insufficient.

I'd probably phrase it as "Stubs and Mocks do not make sufficient tests", not that they necessarily make bad tests.

I wholeheartedly agree that the experience of being a Google customer / user has degraded significantly. I'm not sure the omission of the topics you mentioned can be corelated exactly to that degradation, but it's an interesting idea. My assumption is that all the changes do go through proper UX and user testing, but the reason for them is questionable. I certainly haven't asked for hardly any of the changes. I also assume that the book focuses on the purely technical side intentionally.

I love the way you phrased this and I experienced exactly the transformation you described!

They were asking about forced sterilization though

Agreed, especially the stuff about end users. Of course you want to prevent bugs that will impact users, but many of the other things being discussed have nothing to do with whether there is a non-technical person using the software.

Yes, I agree with this. Everyone is welcome to write their own messy code while in the "get it working" phase, but it needs to be cleaned up and made somewhat verifiable before it is shared with others. I currently work with and mentor software development interns, some of whom are aspiring data scientists, and we make sure to give them training on how to write clean code.

"Really?" was my first reaction too. The difference may be a bit subtle but it's quite clear.

I remember when I was learning promises there was lots of talk in the tutorials, etc. about .all() and I eventually had a use case where I wanted to know the statuses of a bunch of calls and didn't really care whether they were failures or not and I found Q.allSettled() which was perfect. Good old Q.

Reading stories like this really make me hate these customer service walls we've put up everywhere. Only a couple of times in these exchanges did it seem like there was a functioning, thinking human intelligence on the other end. All of the robo-responses are depressing, including the human-generated ones. And it's even more discouraging when you have to hear about their company's internal chaos and disorganization. Really gives me a low opinion of this HackerOne organization.

I would absolutely love to hear someone's experience taking this course: https://www.coursera.org/specializations/coding-for-managers...

I probably won't have time to sit through it, but I've taken a course from this instructor in the past and he is pretty good. I'm really curious to know how he explains coding and engineering principles to "managers, designers and entrepreneurs".

Wow, you just described my world a few years ago. It drove me insane and I quite. Nice to hear that you don't mind it though!

I'm in a similar state of mind as you. Any time I start a web project now I just write vanilla JS and none of my hobby projects has yet to reach a point where I wanted a framework. There have been a couple times, particularly dealing with interactive forms, that I found myself writing a lot of the same code over and over again. I think this would be the first place I would start to build my own little framework. But it hasn't yet made me want to introduce React or Angular to the project. Especially when I consider the hours of free time that I would spend on setup rather than building the actual project itself.

This matches my experience completely. I've never even been offered a session on legalities. Almost universally, my only prep for interviews has been someone leaving the resume on my desk, usually the day-of.

Well said. And to be fair, I was talking mostly tongue-in-cheek about the "idiot", etc. I've been that guy I'm sure.

I agree about the trade-offs, I've been there myself too.

If nothing else I appreciate the author linking to the Ward Cunningham post on technical debt http://wiki.c2.com/?WardExplainsDebtMetaphor

I've heard so much talk about technical debt (and done plenty myself) over the years and it almost always gets used to talk about improving the messy code of the last idiot who worked on the project and didn't know what they're doing. I really appreciated reading Ward's clarification that his original metaphor was about going back and improving the code to show an improved understanding of the problem. Assuming implicitly that the code is clean and well-written in the first place. So now I don't know what to call the effort required to clean up bad code written by inexperienced predecessors. Incompetence debt? Student loans?

From TFA:

from 1939 to 1950, hourly workers’ wages rose roughly three times faster than elite executives’ pay.

This seems like it would be a good place to get back to.

Not sure why this would get downvoted, I think it makes sense. From what I've read about transgendered people, they either suffer through the stress of gender dysphoria and appear outwardly "normal" or they choose to let their outward appearance match their inner identity and would be thus spending all of their points. Not a great choice.

I spent so many work hours devoted to getting elements lined up pixel-perfect to match jpegs from graphic design, and then struggling to get them to also match up in the other browsers. During some periods you even had to fight between versions of IE. Man, those were some expensive pixels!

Yeah this was a wonderful trip back in time for me too. I graduated high school in 1999 so I got to spend a couple teenage years playing around with HTML. I identify strongly with the "copy cool stuff from other teenagers' sites".

At my first web development job in the early 2000's I did some work with SGML. I forget now what I was specifying, but I remember finding it really interesting to be able to understand DTD's. It was like seeing the DNA of HTML. I also remember the miracles to productivity that were Firebug and jQuery!

I would love to see a universal basic income for families with children. My only question is how to change the incentives so kids don't just become a paycheck?

The YouTuber Kitboga mentioned above got into the scambaiting thing because someone took advantage of his grandmother suffering from dementia. It really is a terribly abusive con, and one can learn a lot about their methods and intents from watching his channel.

I subscribed to NYT based on the number of interesting articles that get posted here and their consistently high quality.

I won't subscribe to Medium because the quality is very spotty, but I don't mind stories getting linked here. I can check the link first, and it doesn't ruin my day when I hit my Medium limit. If they don't want me seeing their content I'm happy not to waste my time on their site.

I use a 34" 21:9 Dell monitor at work and I love it. As other have mentioned, you can get two super wide or three reasonable windows side-by-side, which is great. And I like the option to have a super wide terminal for the overly-verbose Java console output I get to debug.

The Knuth quote stands. It has been and continues to be one of my favorites. It has served me well.

Very nice guide, I wish the actual spec were laid out so clearly. (The spec isn't bad, it just doesn't have it all in one handy list like this).

The sidebar waterfall illustration was cool, and I liked that it didn't move when I scrolled so I could keep referencing it. That's useful.

The little inline quizzes were unexpected, but did help me double check that I was understanding the explanations.

These logos are incredible, and so many of them have stood the test of time so well. The mind boggles at the ones that were "redesigned" by some other agency but are essentially the same. I can only imagine the hours that were billed and the meetings that were held debating why those few pixels of difference were significant.

Unrelated to the logos - the graphic design of the site itself is horrible. The dark gray tones make it look like a UI element in the "grayed out" disabled state. And the contrast between the background and the text is far too low.

Yeah that is hairy. And I would say that for many organizations, if a group decides to attempt the extraction and reuse of a module, they should be prepared to adopt the mindset and working style of a library maintainer. Because once you get other people using your module (the point of reuse) you are automatically going to get multiple points of view on what needs to be improved and changed. You're going to end up being a library maintainer anyway, so you might as well go into it with eyes wide open.