< Back to the archive

Like what you see? Subscribe here and get it every week in your inbox!

Issue #67 - June 14, 2020

Here are the top threads of the week, happy reading!

Top comment by foxfired

First of all congratulations. A lot of Show HN start enthusiastically and then a year later the domain name doesn't resolve anymore. I'm glad you kept jabbing.

In 2011, we were knee deep in google products. We used Google Analytics and the now defunct Google Web Optimizer (no not the one in GA). Our business team wasn't too happy about using GWO. There was something in the script triggered bounce rates in Google Analytics.

Our first solution was to build a script to manage which script to load first. But, we saw that if you don't load GA right away, the metrics were somehow off. But loading GA first sometimes double counts page views.

So as a result, I build an internal A/B testing tool that worked seamlessly. Since it was controlled in the back-end, I could decide when to load the script without causing the double page views. After months of testing, the business team decided to use Visual Web Optimizer. I was pretty pissed.

But, vwo solved the issues of double counting, and redirect. Not sure how it worked but everyone was happy about it. I started working exclusively with this tool and implemented it in a dozen teams. It was a great tool.

But then, a new manager was hired, he said he knew a better tool, and moved our team to optimizely. There was no reason whatsoever. Until I left, I kept recommending and implementing vwo in other teams for a/b testing.

Top comment by audiohermit

Hey, speech ML researcher here. Make sure you have different recordings of different contexts. fifteen.ai's best TTS voices use ~90 min of utterances, some separated by emotion. If you're having her read a text, make sure it's engaging--we do a lot of unconscious voicing when reading aloud. Tbh, if she has a non-Anglophone accent, you're going to need more because the training data is biased towards UK/US speakers.

If you want to read up on the basics, check out the SV2TTS paper: https://arxiv.org/pdf/1806.04558.pdf Basically you use a speaker encoding to condition the TTS output. This paper/idea is used all over, even for speech-to-speech translation, with small changes.

There's a few open-source version implementations but mostly outdated--the better ones are either private for business or privacy reasons.

There's a lot of work on non-parallel transfer learning (aka subjects are saying different things) so TTS has progressed rapidly and most public implementations lag a bit behind the research. If you're willing to grok speech processing, I'd start with NeMo for overall simplicity--don't get distracted by Kaldi.

Edit: Important note! Utterances are usually clipped of silence before/after so take that into account when analyzing corpus lengths. The quality of each utterance is much much more important than the length--fifteen.ai's TTS is so good primarily because they got fans of each character to collect the data.

Top comment by Jeaye

- GNU/Linux + i3wm; complete control over my programming environment.

- bash + GNU coreutils; seriously, take the time to be able to write helpful bash scripts which can run basically anywhere.

- git; use it even when you're not pushing to a remote. Add helpful aliases for everyday commands. Build a good mental model of commits and branches to help you through tough merges. ( my ~/.gitconfig: https://gist.github.com/jeaye/950300ff8120950814879a46b796b3... )

- Regex; combined with bash and your GNU tools, a lot can be done.

- Vim; modal editing and vi-like navigation can blow open your mind. Explore the existing plugins to accomplish everything you want to be able to do. It's all there. ( my ~/.vimrc: https://github.com/jeaye/vimrc )

- Functional programming; if you're new to this, start with Clojure, not one of the less-practical languages. This has made such a huge impact on the way I think about code, write code, and design code that it's possibly the biggest one here for me.

Top comment by ritchiea

First I would take a step back and try to view the situation with less judgment. It's easy to look at the past and mythologize it and imagine it as perfect. Maybe there are more MBAs and executives and thought leaders today but the past you're romanticizing would have its own frustrations and road blocks.

The other thing it sounds like you're doing is looking around for a great opportunity rather than zeroing in on a thing you really care about and working on it. Your comment about engineers being a peasant class makes it sound like at least a part of you is more concerned about status than doing the kind of work that you say you're interested in.

Sounds like you need to answer for yourself what you're really looking for, how you would like to spend your days, what you would be proud of looking back on, etc. Rather than looking outward at the state of the industry, the status of developers, phds, MBAs, VCs or execs. If you want to build, start working on a product, figure out a market for it. But also know that at some point products do need to be sold, so eventually, you or a co-founder or your employees are going to have to figure out how to make money.

One of my favorite general pieces of advice is "you can decide what you want but you can't decide what it will cost you." You can decide to be a builder and an engineer but it probably won't come with the adulation you feel for Jamie Zawinski or Alan Kay. And if you talk to most people who are admired and have a lot of adulation, even if it's deserved, it's not something they tend to say they relish. They tend to still relish the work they valued for themselves and feel the adulation is overblown or doesn't actually give them anything of substance.

Top comment by tikhonj

In my experience, "code quality" vs "features" is simply not a real tradeoff. Writing clean code with tests, function documentation, a good level of modularity, automated deployments... etc will save you time in the short term. It's pretty simple:

1. Writing quality code is not substantially slower in the first place, especially when you factor in debugging time. You just have to have the right habits from the get-go. People avoid writing quality code because they don't have and don't want to build these habits, not because it's inherently harder.

2. After the initial push, code quality makes it much easier to make broad changes, try new things and add quick features. This is exactly what you need when iterating on a product! Without it, you'll be wasting time dealing with production issues and bugs.

The only reason people say startups don't fail because of code quality is that code quality is never the proximate cause—you run out of funding because you couldn't find product-market fit. But would you have found product-market fit if you had been able to iterate faster, try more ideas out and didn't spend 50% of your time fighting fires? Almost definitely.

Pulling all-nighters dealing with production issues, spending weeks quashing bugs in a new feature and duct-taping hacks with more hacks is not heroic, it's self-sabotaging. Writing good code makes your own life easier, even on startup timeframes. (Hell, it makes your life easier even on hackathon timeframes!)

Top comment by dpc_pw

Personally, at some point Rust was just clearly better and after a while - I lost interest in D. I don't have time to keep track of D catching up, when I'm so happy with Rust, and ecosystem is growing so fast. Maybe D got much better in last few years... but I kind of don't care anymore. It's hard enough to introduce a raising star like Rust to your coworkers and D just don't have traction anymore.

I've been following D since early 2000s. 2 decades. It took it a long time to get good: make it open source, make it community driven instead of one-man show, add some really important features and focus on important things (ownership, memory-safety), get the tools to be good.

It just missed the boat, and never really had a right niche for itself. It was kind Java/C++ mix, and it wasn't all that better to dethrone anyone in that space.

Rust swooped in and executed everything perfectly in a really short time. It's a C++-killer: same strengths, none of the weaknesses. Normal people don't want to touch C++ anymore. Only people that think that CVEs are "just fault of bad developers" (LOL) can still be considering C++ a good language to start new projects in. Industry really, really needed C-like language that was memory safe, and all-round good: both low and high level. And Rust quickly delivered that, borrowing all the great aspects of other languages and addressing a lot of problems.

D is great, and I like it far more than e.g. Go, but it was an ambitious project by one individual for a long time, while Go had a whole Google behind it. There's no shame that it didn't "took over the world". Rust would possibly not do so well if it wasn't for Mozilla support. The marketing, credibility and traction a big backing company like this gives a new language is probably the single bigger reason for different outcomes.

Top comment by austincheney

Here is what it means to work at a big company:

* Things work slowly, so relax. There are many people that have a hand in every aspect of a product decision.

* At a startup you are actively changing the world. That’s done now. Put that completely out of your head. You are cog in a machine. Instead focus on your assigned product, help your teammates, and just learn to relax.

* You, the individual, are not important. The product is important, the department that delivers the product is less important, the teams that comprise the department are less important than that, and so on. Again, accept the reality and just relax.

* Do your best. Unlike at a startup, generally you will have time to get things correct. This is the difference between competence and others who struggle to get things right and always appear to be in a hurry. There is no reason to be in a hurry.

* Expect insufficient test automation, lots of regression, and plenty of repetition. Also expect everybody to be an expert that is in a hurry and things in a unique way. Just be patient, politely nod, and just relax.

* If you are good at systems automation then learn to automate away as much of your job as you can. Use the now increased free time to contribute to documentation and internal knowledge repositories. You will find that a lot of the documentation can be automated as well.

* My employer has something like 270,000 employees so it’s forgiven if you have no idea what all of those people in your cubicle farm do. You need to actively spend at least 2 days a month answering those questions.

* Just because you are at a big company does not mean you are safe. I have been in a large established super well known .com that failed. People get laid off even when big companies are healthy.

* If you don’t like being bored and are highly risk adverse you might find the big company life highly depressing. A lot of my advice here is to just relax, but I hate relaxing.

Top comment by mtmail

OpenStreetMap is looking for caching servers, those need a lot of outgoing bandwidth https://wiki.openstreetmap.org/wiki/Servers/Tile_CDN

Top comment by MrsPeaches

The Art of Electronics taught me most of what I know about electronics.

It has informal and approachable style and even has a companion study book full of experiments. [1]

One of my favourites from my university days was also Introduction to Heat and Mass Transfer. [2]

Universe is a great introduction to Astronomy [3]

Wind Energy Handbook is also a comprehensive introduction to... well I think you can guess. [4]

[1] https://learningtheartofelectronics.com/

[2] https://www.abebooks.co.uk/9780471457282/Fundamentals-Heat-M...

[3] https://www.goodreads.com/book/show/705558.Universe

[4] https://onlinelibrary.wiley.com/doi/book/10.1002/97811199927...

Top comment by CapitalistCartr

A few useful phrases to memorize:

When someone asks for information, rather than try to answer immediately, or rush to research, ask, "When do you need that by?" Even if they tell you it's urgent, it causes them to consider.

"Sure, I'd be glad to. Just let my boss know you need me." If they hem and haw, be suspicious.

"What budget is that coming out of?"

Other useful tidbits: Politics is a euphemism for, someone's ego will otherwise get hurt. Tangentially, your ego isn't you. Don't let it getting hurt affect your thinking.

Most people are naturally good; the one's who aren't work hard to position themselves in a position handling communications. So be careful to route communications as directly as allowed, and regularly check what's incoming.

Faith is blind, trust is earned.