biocomputation

I'd be embarrassed to recommend it just because it has such a terrible, "me too" name.

Really? How so?

Thanks for the information! I too thought the article would be able innovation and markets.

America definitely does not need more H1B workers.

Yeah, they need to be unaware of them...

Strip them of their citizenship.

Now.

Yes, the culture is affected, for better or worse. Lately it seems like it's been for the worse. To me, the crowding and traffic are the most significant problems. In addition, it's been proven time and again that over-reliance on specific industries is very, very bad for cities and regions. See also: the steel industry in the Eastern United States, aerospace in Seattle, and the tech crash of 2001 in the Bay Area.

That's why we should distribute tech. Yeah, there are benefits to clustering, but at a certain scale the negative affects start to outweight the benefits and simply induce misery. See also: what's happening in SF, Seattle, and other areas where tech has far too much influence on how everyone in a city/region else has to live.

As a programmer, I'm certainly not against tech, but I think industries should have some sort of collective ethics about taking over certain places.

I've lived in Seattle my whole life.

Noted.

I'm fortunate(?) enough to have spent a lot of time in Silicon Valley; cumulatively ~9 months of my life in the past few years.

I used the word fortunate because my time there has only convinced me that it's somewhere I would never want to live, being as crowded and expensive as it is. It also reminds of Washington DC where everyone wants to know what you do for a living right away. It seems like everybody's got a plan; it's kind of like Nashville with a tan.

I hear all these arguments like 'talent center' and 'network effects' and 'efficiency', but then look at the results of cramming all that talent into such a tiny area: stress and misery. We can go on and on about building more houses or condos. In fact, they could build thousands more houses and condos and make it all perfectly affordable for everyone.

But then what? Who wants to spend 3 hours getting over 17 just to go to Santa Cruz? What about parking once you get there? Do you want to wait for an hour for a chance to get one of the spots at the tiny parking lot above the water? Long lines for ice cream and water. It would be like the Hamptons in summer, which is to say it would be dreadful.

Even if you can afford it, who wants to live that kind of life? Just so that billionaire so-and-so can have another jet or another yacht or another mansion?

It just doesn't make any sense to me at all. I think it would be much more efficient to have multiple tech talent centers all over the country. I think most network guys would also say that such an arrangement would be more fault tolerant. I'm a programmer, so I guess I would say that it would make tech more loosely coupled.

Probably. Beer is fine, but I don't really drink that either.

Sounds like I'm not the only one who gets headaches from wine.

You're exactly right. American citizens should never have to compete with foreign nationals for anything.

>> You think MariaDB would choose jemalloc if it wasn't efficient in memory use?

I don't think this is a smart way of choosing an allocator.

I am responsible for a 1.1m LOC application. It's a whole bunch of separate DLLs.

>> Atom's primary innovation

They couldn't make it fast on modern hardware?

It's a significant indictment of the technology, and of GitHub's engineering that a product like Atom is slow on th high-end Dell hardware that my employer buys for me.

Atom's problem, which includes the astoundingly enormous amount of CPU and memory that it guzzles, is that the people who built it demonstrably didn't care about performance, didn't know better, or both.

Atom is a textbook example of how not to write software. I guess it's not only 'hackable to the core', but 'inefficient to the core'.

It's just bad software.

I was actually just a kid, so I don't really have nostalgic views of computer performance from the 1980s.

I do remember typing reports in Notepad. We had a PC because my parents couldn't afford a Mac.

It would be great to post a video or some actual performance numbers, but I don't know where I'd get my hands on a 286 running the original version of Windows.

Atom is ~30 years newer than the original version of Windows Notepad, and Atom runs on hardware that is orders of magnitude faster than the 286 on which early versions of Windows ran.

Yet Atom is still slower and laggier than Notepad running on Windows in 1986.

How did GitHub manage to pull off that feat? Given the fact that faster programs were made 30 years ago on vastly inferior hardware, Atom's performance absolutely deserves to be criticized.

I can start Visual Studio right now and make a simple Windows desktop app in an hour with a text editor whose performance ( startup/ file load / editing ) will blow Atom away.

I haven't done any statically typed functional programming. I'm interested in some parts of functional programming, mostly as they related to replacing raw logic with functions.

Why is Google ( or any other employer ) your holy grail? Is getting hired at a big five employer seen like the Olympics of software development or something?

I'm genuinely curious.

It's like we're the same person.

I've found it next to impossible to get it through ( some ) people's thick heads that refactoring is not a sign that something was done wrong the first time around.

>> We learn good design best by refactoring.

Exactly. This is often when the true value of a design pattern becomes crystal clear in an applied ( rather than theoretical ) sense.

I was once actually accused of vandalism!

This is exactly how I work!

>> did cause some missed deadlines early on, and getting all the abstractions correct still means basic functionality often doesn't come together until the last minute.

Yes, yes, yes.

>> I think most managers would be horrified this approach

Yes, been there, done that too!

Yes, to me, 'software development' is 'refactoring', just like some authors say that 'writing' is actually 'rewriting'.

You're right, I'm just saying that it's not always possible to see these problems in advance, and that it can be very difficult to try and get something done if you apply too many rules to a nascent system ( too many rules == design by committee ).

Yes, and systems that one might refer to as 'disruptive' often get traction because they don't have the same gravitational pull as the incumbent. Maybe magnetism is a better term because feature richness often correlates with complexity, and that can attract and repel people.

I agree. Very often I see this set forth as a problem with management, but it seems to me that other engineers are also a significant part of the problem. I try really, really hard to never be that engineer. If someone sees defects in something I wrote, regardless of the scope, I'm totally fine with whatever they do to make it better, up to and including totally replacing my work.

Depending on what you're doing, the right decisions might only be visible in hindsight.

To this point, you might scaffold out a system to get something running and then incrementally / organically improve the system. I regard this as 'getting the system to the point where it can be dogfooded and/or criticized in a helpful way'.

At this point, despite what you might have running, it may be exceedingly clear that you should have used a different strategy. Maybe you like the overall results, but you need things to be implemented in a different way.

For example, I'm a C++ programmer. It's not always obvious at first that you need a specific set of virtual functions to make something work really nicely.

It's impossible to always know these sorts of things in advance.

Interesting perspective.

With respect to technical debt reflecting organizational problems:

I've always been surprised at how much internal resistance (management and other programmers) I've faced when trying to pay down or eliminate technical debt, regardless of whether it was my code or other people's code. ( For the record, I've written plenty of bad code in my day. )

In the past when I was foolish enough to try and be deferential, I was given excuses like 'yeah, we don't want that kind of churn in version control' and 'we have to maintain compatibility' even when compatibility isn't an issue at all. This, more than anything taught me that it's better to seek forgiveness than permission.

Love the concept of building technical wealth. That's a great way to put it.

I'm using Electron ( shell? ) to make a simple desktop app. Certain things are much nicer, such as the ability to have everything be "owner draw" in a way that isn't as frustrating as using owner draw in the usual context. IE, I can easily at a bitmap background to whatever component I want. I can control a lot of the look/feel of the UI with style sheets.

IMHO, React is another way of covering up 20 years of bad design decisions that went into web tech. React is the natural reaction to using a tree of text to represent data structures. If things were done right, React wouldn't exist. By 'real modules' I mean things like DLLs that can be hot swapped at app start or at runtime. The more I look into things like Atom, the more I am disturbed by what constitutes 'state of the art' in web tech.