mekane8

Joined 14 years ago

Karma
94
Submissions
101
Member since
Nov 20
Software Engineer since 2003
View on Hacker News

Recent submissions

Comment · 2 months ago
This was a beautiful read. I work from home 100% but I do enjoy occasional trips into the office to see people in 3D. I completely relate to the decompression time of the commute - I used to have a 20 minute bus ride (no transfers) which was perfect.

Saving my brain from attention fracture via smartphone is a big theme for me right now as well. That's a whole other effort, but I appreciate the use of workday routine as a countermeasure against phone addiction.

Comment · 1 year ago
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.
Comment · 5 years ago
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.
Comment · 5 years ago
Comment · 5 years ago
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.

Comment · 5 years ago
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.

Comment · 5 years ago
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.
Comment · 6 years ago
I love the way you phrased this and I experienced exactly the transformation you described!
Comment · 6 years ago
They were asking about forced sterilization though
Comment · 6 years ago
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.
Comment · 6 years ago
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.
Comment · 6 years ago
"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.

Comment · 6 years ago
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.
Comment · 6 years ago
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".

Comment · 6 years ago
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!

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton