Handmade: A Community for Self-Rolled Performant Software (2016) - <AUTHOR> https://handmade.network/manifesto <comment><USER2> Hey! I organized this community a few years ago; it's under great leadership. Trivia points:

1\. The manifesto author was barely 18 when he wrote this; representative of a new, younger cohort interested in this stuff.

2\. Handmade is into low-level understanding, but certainly a few people stick to high-level projects, and simply peek behind the curtain when they _need_ to. Low-level thinking translating into high-level wins.

3\. Someone mentioned my conference, Handmade Seattle [0]. This is part of an effort to expand into the mainstream, and to inspire the next generation of compiler writers, kernel developers, game engine programmers etc.

We're not saying _everyone_ has to be into this. We want to carve out our place, let those who care flourish, and not be caricatured for "reinventing the wheel."

[0] [https://www.handmade-seattle.com](https://www.handmade-seattle.com)

</comment><comment><USER3> The handmade hero community is wonderful. It is a portal to a lot of knowledge transfer. If you're looking to approach C/C++ in a welcoming environment and/or love getting closer to the metal, I highly recommend the community.

I also recommend the handmade video series.

Casey Muratori has been live streaming himself build the same game for the past few years. He try's to build everything from scratch, which is entertaining and quite the brain dump.

Also, the video archive and live chat is searchable. I can't count the number of times I

\- searched for some keyword or phrase, like "CPU"

\- was greeted by a link that read something like this

 _" Day 025: Finishing the Win32 Prototyping Layer (01:38:59) Isn't the CPU Memory bandwidth only valid for on-die memory?"_

\- clicked the link to receive 3-10 minutes of extremely dense but well- explained information on a topic.

\- spent the next hour or so googling technical terms and subjects that filled massive holes in my knowledge.

If you love learning, treat yourself to jumping around the video archive :)

[https://guide.handmadehero.org/](https://guide.handmadehero.org/)

Two favorites of mine from the archive Undefined Behavior: [https://guide.handmadehero.org/chat/chat011/](https://guide.handmadehero.org/chat/chat011/)

Modern x64 Architectures and the Cache: ([https://guide.handmadehero.org/chat/chat017/](https://guide.handmadehero.org/chat/chat017/))

P.S. Its worth mentioning that you can buy the game hes building and get access to the source code. I'm not associated with handmadehero.org or Casey Muratori in anyway. The community just led to me becoming a better programmer over the past 5 years. I hope someone reading this finds the value I did in rabbit-holing for hours and laughing at the rants of a seasoned game dev.

*edit: formatting

<comment><USER4> There also used to be a meetup in Seattle [https://www.handmade- seattle.com/](https://www.handmade-seattle.com/) (which has since moved online due to the pandemic situation) but in the past they had some pretty good presentations and interesting speakers. You can find some videos of them online (Youtube: "HandmadeCon" and "Handmade Seattle") although regrettably there are no recordings of last year's meetup.

<comment><USER2> I'm in the process of getting a few of them officially up. I had lost contact with the cameraman after COVID, but we're in touch again!

<comment><USER4> That is great to hear Abner, thank you very much for all your efforts! Because I couldn't make it to Seattle last year, I missed the entire thing, it would be awesome to see some of the presentations.

</comment></comment></comment></comment><comment><USER5> Why is that we praise hand-crafted objects in the real world while at the same time deriding such hand-crafted code as a quaint curiosity that can only make sense as a hobby of the hopelessly romantic?

Do we compare your local carpenter with IKEA, or that delicious, nutritive and healthly meal you cooked with McDonald's, in terms of pure (developer) performance?

Do we obsess over how a handmade jewelrer can't scale operations to five continents?

Why do we copycat every process or idea from tech behemoths but laugh when someone tells us that maybe a chat client shouldn't gobble up gigs of RAM?

In the real world, both craft workshops and assembly lines have their place. Maybe that should be true for the digital world as well.

<comment><USER6> Carpenters still use harvested, dried, milled lumber. Chefs still use harvested, dried, milled flour.

Frameworks are tools and building blocks like this, but for software. Not using them is not like an artisan carpenter using lumber from the store. It's like a carpenter making their own boards, or a chef making her own flour. It is not really relevant to efficient, performant software, it is more like an art for the sake of it.

<comment><USER7> > Frameworks are tools and building blocks

Tools, maybe, but I have yet to see anything that calls itself a "framework" (i.e. Spring, Angular, Django, Salesforce) that doesn't a) bloat the hell out of the binary, b) use more memory than it can possibly justify, c) create impossible-to-diagnose problems, d) not actually provide anything except overhead.

<comment><USER8> The best framework I've used is probably MonoGame. It abstracts away accelerated 2D graphics across multiple platforms, asset loading, and input handling, among a few other things. You write your game not against DirectX, but against the concepts it introduces. Unlike modern ideas of frameworks, it doesn't preach to you that you need to name things certain ways, or impose other slightly-pedantic notions on you.

Instead, it's focused on getting out of your way. Most other frameworks seem to love getting in your way, because they see themselves as so important.

</comment></comment></comment></comment><comment><USER9> What people don't realize is that modern, high-level languages and abstractions give you much more than just speed of development.

If you use a garbage collector, you don't have to do manual memory management, which is amazing for security. You also don't need to worry about buffer overflows and weird pointer exploits.

If you use web tech, you get a lot of important stuff, like sandboxing, handling of esoteric keyboards, RTL languages and screen reader accessibility almost for free. If you use some extremely fast, small and lightweight GUI framework, you will probably not implement those, as they seem boring, and who needs that anyways.

If you go the handcrafted, lightweight and fast route, you're sacrificing a lot of features, possibly without even being aware of what you lose until it's too late.

I will happily shelve a few more bucks for RAM and wait a few more seconds to get an accessible, secure Messenger, instead of one that is going to steal my bank details the moment some stranger sends me a malicious GIF.

<comment><USER10> A pedantic point, buffer overflow protection and the GC are separate things. Buffer overflow protection is bounds checking, GC's are ensuring memory that is no longer in use is reclaimed. But the boundaries on the programs you mention, are more to do with the system not allowing these actions than the language.

Also, there are other ways to achieve memory safety for all but maybe a few cases without a GC. One being ref counted structures that have loops in the links. Another case, but it has work arounds, is postponing the cleanup until a later time. But C++ provides guarantees like, at scope end the destructors(finalizers) are run and the values are cleaned up. This allows for more than memory safety and can include other resources too. This is easier in greenfield projects where old idioms/C compatibility are more common.

To add to your point, high level abstractions allow for optimal code as it is more declarative. The low level constructs to make it fast are of no concern to the caller. And one can build upon this for new higher level abstractions.

<comment><USER11> What is your point? The way refcounted smart pointers are used in modern c++ doesn't come close to addressing all the memory safety issues. Iterator invalidation, bounds checking, use of uninitialized memory, use after move, dangling reference (outside the aforementioned cases), etc.

What they're pretty good at is solving for use after free. Even there, caveats apply (see widely documented thread safety fiasco of shared_ptr).

</comment></comment></comment><comment><USER12> I've been writing C code for more than 30 years, C++ for 27. I've written code at every level of "the stack", from kernels of several nix-related operating systems to application GUIs. I've worked on "plumbing", on libraries, and on applications.

And here's the thing: I understand, at a very very deep level, precisely why my application is slow to start up. I understand it at every level from the semiconductor gates in silicon up to the color specification lists used by the GUI toolkit. But none of that helps me make it as fast as the handmade community thinks things should be.

Why? Because I know that the slow startup is caused by substantial amounts of code that all add useful functionality for at least some of my users. Do I want to get rid of i18n? Shall I skip checking for new versions? How about forcing plugin scans to be initiated by users and never doing them automatically (don't even _think of_ suggesting doing them in another thread, and don't ask me why)? Shall I skip the ability to handle RTL text? Should we drop human readable and editable configuration files in favor of some faster and less resource-eating format? How about a scalable GUI, is that really useful for most? How about a themeable GUI, given that it's not actually that themeable anyway?

And so on and so forth. Each one of the above (and lots more) contributes just a little bit to the slow startup. For most users, all but one of them will likely seem not very important. So which ones do we drop to get back to the sort of startup times that the handmade community seems to expect?

Because let's face it, xterm can put a window on the screen before my finger is off the return key. So why not a DAW (or an IDE or an editor or a vector graphics app or an image editor or a browser or a circuit emulator or whatever your thing is) ? Just which features do you want to cut to accomplish this?

<comment><USER13> Let's call 1 second the threshold for a bare system with an SSD and 4 core CPU at 2Ghz. That gives you 8 billion cycles to start up, trading off with file access, so maybe only 4 billion of those have access to all the data you need in memory (modern ssd loads what, 400 MB/s?).

So all the startup code and initial assets are larger than 200 megabytes and take more than 2 billion cycles to prep? Computers are fast, software is slow. Sure, things aren't trivial to always fit in that package, but it's disingenuous to say you need to take many seconds to start up.

Look at a giant piece of software that was built for more limited times: Visual Studio. It used to start up in milliseconds back in 2000. Now it takes 30 seconds. Did it really improve things so much to justify that in the intervening years? I'd go with no.

You know what else has an amazing set of features and capabilities including internationalization and accessibility and all those other complicated things? Web browsers. And there's not a browser on the market that doesn't start up in more than a couple of seconds, including loading a full webpage and rendering it from the internet.

<comment><USER12> Well, maybe I'm being too harsh on myself. Timing Ardour on my machine (Ryzen 2950X with 64GB of RAM), it has something on-screen is less than 1 second. But actually loading a "significant" session is more like 6 seconds. There's approximately 300MB of data in the session in total, but most of that is audio data that isn't being read at startup.

I've seen DAWs start up massively faster than this, though. And also slower. Essentially I have some intuition that "correct" software design would appear to the user as a more incremental startup: the window would appear as rapidly as xterm does, and would slowly fill with everything that makes up the actual program. I personally find this hard to design for. Could be me, or the GUI toolkit I use or maybe it just is pretty hard.

As for browsers, "a couple of seconds" has some slop. When I restart Firefox here, with typically 100-200 tabs and the main/primary/#1 tab being gmail (unfair! i hear you cry), I'd say it was more like 5-10 seconds until it is usable.

</comment></comment></comment><comment><USER14> While "handmade" code may be faster, it's also a big time sink and as a developer your job is to make tradeoffs.

For most software, you should probably focus on architecture instead of the lower level of your code. Sane code and architecture solves most performance issues. This includes technology decisions, like using web tech for applications instead of the native platform.

For example, Apple has had a lead of at least five years over Android when it comes to performance and user experience, because their system and apps were all built in native environments, instead of the JVM abstraction layer. It took at least five years for Android to catch up, and it took quadcore CPU's to do it. Around then, Apple carefully started using dual-core CPUs.

Meanwhile, companies like Facebook and Twitter spent dozens of work-years on trying to make web technology feasible in native apps and never really cracked it.

If they had just focused on building good native apps they wouldn't have wasted so much time.

Caveat / Aside: IIRC Facebook is having / has had massive issues with having too much code / classes / files in their app(s), on both iOS and Android. Which is (I believe) one of the reasons why they split off Messenger into its own app at the time.

<comment><USER15> Here's the fundamental difference between iOS and Android, and it's related to memory management:

On iOS, you pay for memory management in small installments, which make your code slower overall (reference counting in ObjC/Swift), but predictably so.

On Android, you pay almost nothing for memory management until at some random point the garbage collector shows up and stops your program to clean up your mess. Your program is going to be janky.

Apple deliberately ships devices with little RAM and kills applications that use too much of it. As a developer you better pay attention, or you will be flooded with bad reviews.

Google leaves RAM up to vendors. The secret to good performance with GC is to make the heap twice as large as the data which it contains. Low-end Android devices _feel_ low-end, not just because of slower CPUs, but also because of too little RAM.

It has nothing to do with the "JVM abstraction layer". Java code on a good JIT easily runs faster than Swift or ObjC if there's a lot of allocations involved, but the GC behavior must be accounted for to give a good experience.

</comment></comment><comment><USER16> "Why does it take your operating system 10 seconds, 30 seconds, a minute to boot up? Why does your word processor freeze when you save a document on the cloud? Why does your web browser take 3, 4, 10 seconds to load a web page?"

Bloat !!!

</comment><comment><USER17> The Handmade metaphor masks a key difference between software and physical goods. IIUC, mass-produced physical goods are inferior to their handmade counterparts because of the trade-offs that enable profitable mass production. So we have a strong emotional attachment to handmade things being better, and the Handmade movement plays on that emotional attachment.

But the metaphor breaks down if you think about it. A carpenter making a single piece of furniture can tailor it to the person who will be sitting on it. A cook making a meal for one person can tailor it to their dietary requirements or tastes. But software of any non-trivial scale is rarely written for one person. Even when it's developed according to the ideals of the Handmade movement, it will be mass-distributed.

I actually think that, contrary to our intuition about handmade things, Handmade software tends to have compromises compared to software that builds on well-established components. I won't repeat miki123211's top-level comment [1]. I'll just add here that it's precisely the economics of large-scale software distribution that allow concerns such as internationalization and accessibility to be addressed, while a solo Handmade project will probably not have these important things.

So, while slinging JavaScript code with no regard for performance and packaging it with Electron is certainly not the ideal, I strongly believe that the Handmade approach isn't either. As is so often the case, we need a middle ground.

[1]: [https://news.ycombinator.com/item?id=24186711](https://news.ycombinator.com/item?id=24186711)

<comment><USER18> _> As is so often the case, we need a middle ground._

This is not a popular opinion here, but: the middle ground is writing handmade native apps using native OS widgets. You get both the speed and a mature environment to work with.

If you follow the platform conventions you will probably have better accessibility and internationalisation support than Electron. They will run fast as a bullet. They will consume a puny amount of memory. They will have dark mode for free on macOS. They will look like most other applications that come with the OS. It probably also has a graphical editor that will make your job easier (.NET, MFC, Cocoa, all have).

If it's something like .NET you won't even have to worry much about the "Turkish internationalisation Problem" that we were discussing yesterday. [1]

Things like localisation that require a framework/library in the web world are probably handled by the libraries provided by the OS vendor.

If it's "handmade", you're already putting a lot of effort that you wouldn't put in your day job. Why not use that effort to port directly to each platform, instead of recreating everything from scratch?

For Linux the situation is more complicated, of course, but maybe Qt is acceptable?

[1] [https://blog.codinghorror.com/whats-wrong-with- turkey/](https://blog.codinghorror.com/whats-wrong-with-turkey/)

<comment><USER17> I mostly agree with you. But which toolkit for Windows is the "native" one? This is a well-known problem with Windows development, so I won't belabor it here. Hopefully Project Reunion improves the situation. But the murky state of native development on Windows is a big reason why developers just throw up their hands and go with something non-native that at least will work consistently all the way down to Windows 7 (or XP before that).

Disclosure: I work for Microsoft, but on the Windows accessibility team, not on a UI framework or developer tools.

<comment><USER18> Glad to see someone from Microsoft interested in seeing this issue solved. :)

Well, native for me is whatever provides native look and feel. Win32 if you want C/C++, WinForms (yeah I know) if you're ok with C#. Most people featured in the article's website would only consider "truly native" as being Win32, though, which is fine.

</comment></comment></comment></comment><comment><USER19> It reminds me of [https://suckless.org/](https://suckless.org/)

Also the set of projects is somewhat similar:

window manager (dwm) -> game engine library (raylib)

terminal emulator (st) -> IDE template (4coder)

web browser (surf) -> video browser (motionbox)

\+ tools and libs...

</comment><comment><USER20> I love all the game engines in there! Really makes me feel like hacking some game together to test them!

</comment><comment><USER21> Interesting what words the manifesto doesn't mention: correctness, security, safety, bugs.

</comment><comment><USER22> Damn, this place looks amazing, it looks like El Dorado in a sea of despair, for someone being used to make the same points than this manifesto and being looked as a weirdo in response.

Sadly they block Tor users, because they use Cloudflare. Maybe we're not that much on the same page after all.

<comment><USER23> Cloudflare doesn't block Tor users by default and I just visited the site using TBB: [https://imgur.com/a/GHpbvTD](https://imgur.com/a/GHpbvTD)

<comment><USER22> Are you kidding? Or is it corporate speak, like "it does not block Tor, only 99% of its users"?.

Cloudflare is what makes the web unusable for Tor users. Every two websites you try to reach, yup, blocked by Cloudflare. The fact that you try to deny it makes it painfully obvious how there is no hope for Cloudflare. Sorry, I can't wish any good to your company.

</comment></comment></comment><comment><USER24> TL,Dr : knowledgeable, skilled programmers writing semi-confidential software in C for mostly a single OS, by themselves, with total control of the feature set and release schedule, can produce pretty fast binaries.

Which is great ! I just don't know how to transfer that to building software as a team with multiple skillsets, unknown feature set (because market feet is still searched for) aggressive schedule, (We don't know what we want to build , but we need it in six months), large target audience ("what do you mean they have to install stuff ? Where is the link I can paste in an email so they open it in IE6 ?") , and,let's be honest, less knowledgable and more lazy developers.

(To be clear : I'm _not_ criticizing the network or project. I just find it interesting that they had a goal - making fast software - and that, to the ebest of my knowledge and without a rigorous analysis - it seems that most projects converged on a very particular kind of software. Which just happens not to be the kind most of us will ever be working on, but it does not matter. Go them !)

<comment><USER25> Speed is a very real selling point for software though. If your competitor takes 6 months to get to market, and then is locked-in to a bloated, sluggish, badly-architected codebase made from 50 abstraction layers, you have plenty of time to come in later and steal their userbase, when your project is done and can do things in 1/10th the time.

<comment><USER24> My prior in such a situation would be to assume that "stealing userbase" is very hard. It depends on the kind of application, of course, but once you have paying / committed user, I'd assume the friction to change (and natural risk/change aversion )would be in favor of the incumbent.

That being said, arriving afterwards with a message of "we're like X,but faster" could be a good marketing catch, but probably not for any kind of enterprise app. (The only good marketing catch in this case would be "we're like X, but cheaper.")

No idea how such an hypothesis could be tested. We would need records of user switching from an app to another.

</comment></comment></comment><comment><USER26> So the bottom of the linked article says 2016, which made me immediately think 'old!'

It makes complete sense for the manifesto to be timestamped, but the surprise was that I didn't realise I was reading the manifesto rather than this actually being the normal landing page... there's no title or anything and HN usually links to homepages.

But a quick glance at the forum and the homepage shows there's activity there still!

Clicking around, this seems really interesting :)

<comment><USER27> > So the bottom of the linked article says 2016, which made me immediately > think 'old!'

I yearn for the day when the industry reaches a state of reliability where we see "old" as a good thing, i.e. "this problem was solved ages ago!", rather than it seeming out-of-date.

Probably not in my lifetime!</comment></comment>


A path tracer in 300 lines of C++ - <AUTHOR> https://github.com/hi2p-perim/minpt <comment><USER2> Is this a joke?</comment>


A New Way to Prevent Muscle Cramps - <AUTHOR> http://www.wsj.com/articles/a-new-way-to-prevent-muscle-cramps-1468256588 <comment><USER2> I wonder if this is why tonic water prevents night time cramps.</comment>


Show HN: ChiefApplying – Build career and vacancy pages in seconds - <AUTHOR> https://chiefapplying.com <comment><AUTHOR> It's currently in beta and free to use without any banners / backlinks or whatever.

Feedback is appreciated!</comment>


EventMachine: scalable non-blocking i/o in ruby - <AUTHOR> http://timetobleed.com/eventmachine-scalable-non-blocking-io-in-ruby/ <comment><USER2> This is what's frustrating about being a Tcl fan: Tcl had this something like 15 years ago, because it was necessary for Tk. "Tcl don't get no respect" :-/

That said, though, what separates the "men from the Erlangs" is that in Tcl, Ruby, Python, Javascript, and company, "never block the reactor" is the name of the game, you can't do a while { 1 } { something } in your event handler or it will wedge the whole thing.

In Erlang, thanks to its built in scheduler, you can.

<comment><USER3> Why is that a good thing?

Essentially what you're saying is that Erlang allows you to make idiotic mistakes?

<comment><USER4> No. Things that are _not_ Erlang turn you into a human compiler, forced to manually chop your code into pieces for the pleasure of the computer. Erlang allows you to actually write things without doing the chopping up the scheduler should do.

Event-based libraries are great hacks on top of weak languages/runtimes that allow those weak languages to hobble forward into the present, but they shouldn't be confused for the right approach in the future. I do hope they don't become trendy.

Of course, look for them to become trendy, then for one or more of them to rediscover the pleasure of actually writing code in a straightforward manner, so they will provide you with a preprocessor that tries to do the chopping up for you, but still won't solve the problem of doing too much work in one timeslice. Then they'll rediscover that cooperative multitasking was abandoned years ago for good reason.

You know, there's nothing new under the sun, but sometimes you just wonder... this much hype around _cooperative multitasking_? Seriously?

<comment><USER3> I can't disagree with you enough.

I don't want anything else to decide what order my code runs. I want it to run in the order I decide.

Once you move away from the stupid "I want these 100 things to run at the same time", and realize that's impossible unless you have 100 CPUs, then you can start to move forwards and learn a better way.

Event based / async programming is simple once you get used to it, it's hugely liberating, and _extremely_ efficient. It reduces code complexity, and means you _know_ what order your code will execute in. Something that I kinda like knowing.

<comment><USER5> You don't really know a priori the order everything is executing in, unless you control the remote ends of all the connections and you have no timers. I've lost days of my life to timer cancellation bugs.

<comment><USER3> Sure, you don't know the _exact_ order your code executes if it has external inputs :) but you know that your code will execute 'linearly' and then adhere to any program flow constructs you put in, and nothing else.

You can be 100% sure that it won't suddenly stop executing here, and jump over to some totally disconnected bit of code for a while, then jump back.

You don't have to worry about a whole class of bugs which take up weeks/months of peoples time.

Not sure what you mean @ timers, I was really talking about async/event driven in general. Timers seem like an implementation specific detail on top of that. I haven't really seen any issues myself there :/

<comment><USER4> "You don't have to worry about a whole class of bugs which take up weeks/months of peoples time."

I reiterate, you need to spend some quality time with Erlang. This time I recommend <http://erlang.org/download/erlang-book-part1.pdf> ; Erlang has some powerful answers to those "whole class of bugs".

(Actually, not being aware of that does rather make sense of the rest of your views. I have first-hand experience that Erlang really does make those problems go away; I like to say that Erlang takes concurrent programming from an exponential problem to a polynomial one. It still isn't "trivial" and I don't know that it ever can be, but it makes it so a _human_ can do it.)

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> As luck would have it, I'm sitting here writing a fuzzer for a trading protocol in EventMachine as we speak.

Ruby and async network programming go together like gin and vermouth. It's one of the reasons I'm so happy with Ruby's block/lambda support, and so irritated with Python's: many of the basic programming idioms for evented network code have direct support in the Ruby language.

I've done a fair bit of Twisted Python programming in the past, and I find EventMachine to be far more intuitive and flexible. On the other hand, EventMachine will crash on me once in a blue moon, and it swallows exceptions, which is extremely frustrating. They're both great packages.

The big problem that still needs solving for EventMachine is evented adapters for an ORM (any ORM). You've always been able to talk to MySQL over an evented socket, but that's clumsy compared to DataMapper.

I am still totally not sold that Ruby threads are tenable, so a lot of the "advanced" stuff in EventMachine does nothing for me. It's great even without it.

<comment><USER6> _I am still totally not sold that Ruby threads are tenable, so a lot of the "advanced" stuff in EventMachine does nothing for me._

FWIW, threads based on an event backend are a solved problem in Perl. The Coro library is what EM is trying to be; they should really take a look. ("Oh but it's PERL!!!!" Yeah, and it actually works.)

<comment><USER5> Maybe, but part of the value of async programming is never having to thread, so none of this really lights me up.

<comment><USER7> Honest question: is there a purely event-driven I/O framework (no threads anywhere)?

The one that a lot of people have gotten excited about recently is Node.js and that uses threads for file I/O (libeio).

<comment><USER5> EventMachine doesn't thread unless you ask it to. I use EventMachine in Ruby and libevent in C with nary a mutex in sight.

<comment><USER7> I see. My (wrong) understanding was that EM used a thread pool to do file I/O like Node.js. It appears to add the file descriptor to the event loop's watch list.

</comment></comment></comment></comment></comment></comment><comment><USER8> I recently had a chance to play around with EventMachine, as I wanted to set up an event-based scheduler within my application.

I was not impressed.

If you try and mix 'EventMachine' and 'other threadsafe code', it seems to fall down pretty hard. In my case, it would run anything executed via next_tick, but would refuse to run any timers... unless I defined a periodic timer in the main event loop, after which timers started working... but only every time the periodic timer executed.

I dug through the code to see if I could fix the problem, and gave up after trying to figure out why they seem to implement timers in two different ways, and it doesn't seem very threadsafe (next_tick is, but none of the timer code looks to be).

EM also expects that your entire application will run inside the EventMachine loop; there's no way to ask EM for a Reactor that you can then hand events.

If you're not running threaded code, then EM will probably work just fine; the Thin webserver looks to be a really nice Rack deployment option if you're on MRI.

If you need to mix EM up with anything else running on the same VM, look elsewhere.

</comment><comment><USER9> Take a look at Juggernaut. It's an event server based on EventMachine that provides nice integration with Rails. Streams events to the client via Flash.

</comment><comment><USER10> Excellent preso. If you are interested in eventmachine or just getting into it read this.

</comment><comment><USER11> Great presentation! Some exciting new stuff in Eventmachine.</comment>


Ask HN: Should I take the "sponsorship" deal? - <AUTHOR>

Quick background: for the past 2 years I've been working on a project, a mobile app (Google me if you'd like to see it for yourself, I don't want this post to be an ad).  It recently got a considerable amount of traction. My next step for the product requires a few extra hands on deck and I need money for that.
So far I was reluctant to talk to VCs, because I'd lose some control and I'd have to deal with all the stuff I don't want to (incorporating, papers, lawyers, etc.) instead of working on the product. So I came with an idea: since the app's is a _bit_ hot right now and it has to do with finance a bit, I'd look around for a bank which would be willing to pay for the development in exchange for my project helping them strengthen the image of a bank that understands mobile and new technologies. I'd brand the app a little (splashscreen, link to their mobile app in the menu and a few extra sponsored features), I'd mention them whenever I talk to the media. So I contacted a few banks, met with some people and it looks like this thing might happen.
I also spent the last few weeks talking to a bunch of smart people about my project.  I figured I might learn from their experience and boy, was I right! I got a ton of good advice (and a lot of praises, which nicely tickled my ego).
The last meeting I had put a lot of question marks in my head, though.  I met with Jacob Krzych, CEO of Estimote and an YC alumnus.  I got a ton of good advice (thank you, if you happen to read this :-) ), but one thing surprised me, he said it would be a great mistake to do the bank deal. It would be a distraction and I'd have to compromise the UI. I should talk to VCs instead.
Now I'm torn... we're talking about an amount that would let me hire enough people (4-5) for half a year but I have to agree that my app's interface wouldn't be 100% about the user anymore.
What do you think? <comment><USER2> I don't have an answer for you, but something to think about is this:

Always consider the background and context of the person who's giving you advice.

They may be smart, successful, and experienced, but they're not immune to bias.

If you're speaking with a YC alum or anyone in the VC world, _of course_ they'll suggest talking to VCs. If you're speaking with someone in the finance/banking industry, of course they'll side with the banking deal.

This includes members of HN, too. Hopefully you're able to take all the advice with a grain of salt and make a decision that you feel is right for you.

</comment><comment><USER3> Even without knowing the specifics of the deal, or your site/app traffic, I'd have a hard time accepting the deal based on the exclusivity and cash flow issues in dealing with the bank.

If this bank wants exclusivity, I'd ask for a multiple of their offer. If they don't want to pay it, you can easily shop this around as a white-label tool to apply to multiple verticals: banks and lenders, restaurants, travel, education, etc.

And don't forget that you will likely not see a check from any corporate customer for at least 120 days assuming 30 day for contract and 90 day terms.

I'd also look at alternative lending tools like SMB loans, gov grants, and SMB funding focused startups.

</comment><comment><USER4> The reason startup people are telling you to not do the deal with the bank: banks are large corporations that move extremely slowly. Even going from a verbal agreement to a signed contract may take 6 months. Then getting a check could be another 3 months. Any of those delays could kill you at any time, and the bank couldn't care less. So that's where the real risk is for you: too much imbalance between the two parties of the deal.

That being said, you got to do whatever it takes, so if that's the only way to survive, then sure, do it. Talking to VCs will not be much faster anyway. Angels could help faster probably, if that works for you.

</comment><comment><USER5> With the caveat that there is no right answer, I can tell you as a mobile advertising guy that your users are unlikely to desert you just because you build in sponsorship. Particularly on Android they have been trained to expect ads in free products, and there are plenty of ways to do it so that it flows with the user experience. What I would recommend is that you don't let the bank completely dictate the UI - rather build in the messaging in a way that you yourself would find acceptable. Feel free to ping me if you'd like advice on the ad units.

</comment><comment><USER6> They pay for development, they get branding, but for how long?

The answer might change your thinking. Exclusively theirs forever, less attractive. Exclusively theirs for a year, then no restrictions on what you do next, more attractive. Theirs for 3 years, then you can take it to others who are not their competitors, perhaps less attractive.

It's all in the details.

<comment><AUTHOR> It would be a half a year deal.

<comment><USER6> Six months' exclusivity? Without knowing any other details, this sounds great to me. You get to build something, it is theirs alone for six months, and after that, well...

...were it possible for others to learn what your were doing, perhaps they would sign up quickly on the first day of the seventh month....

</comment></comment></comment><comment><USER7> What about white-labeling? Meaning, you keep the version you have and fork one for them with their branding -- non-exclusive.

Perhaps part of the white-labeled app is bank-specific content in addition to branding (a branch locator, for example).

<comment><AUTHOR> I offered that as an option, they weren't interested.

</comment></comment><comment><USER8> Take the money, and spend it _veeerrrrrrryyyyyy slowwwwly_.

<comment><AUTHOR> That's the idea...</comment></comment>


I Do Not Stand Up for Stallman - <AUTHOR> http://davidbrunton.com/2011/11/01/i-do-not-stand-up-for-stallman/

<comment><USER2> Very well put. Could not have said it better.

Well, except the "Because Stallman said so, that's why."

And now, ffs, lets stop this love/hate fest about RMS. Enough. Al you Steve Jobs fetishists - you guys too! Just enough.

<comment><AUTHOR> HAHAHAHA, touche! Thanks for the perspective ;)

</comment></comment><comment><USER3> Well said. Stallman can take care of himself just fine.

</comment><comment><USER4> Very well written. Thanks, dbrunton.

</comment><comment><USER5> Not what I expected when I reluctantly clicked. Well put.</comment>


In a WeWork World, Finding an Office Buddy Is a Social Minefield - <AUTHOR> https://www.wsj.com/articles/in-a-wework-world-finding-an-office-buddy-is-a-social-minefield-11553873968 <comment><AUTHOR> I was quoted in the article. AMA =P</comment>


John Carmack QuakeCon 2011 Keynote - <AUTHOR> http://www.youtube.com/watch?feature=player_embedded&v=4zgYG-_ha28

<comment><USER2> i stand in awe whenever i see a Carmack keynote. it almost feels like he breathes in once at the start, and delivers a coherent and easy to follow (and i am no game programmer) stream-of-conscience speech for 90-180 minutes without a single pause or the aid of a slide deck.

if ever there was a genius (not throwing it out lightly) who knew what he was talking about...

</comment><comment><USER3> man, I love hearing what Carmack has to say about anything SW related.</comment>


Similarity: unique inserts in the 2019-nCoV spike protein to HIV-1 gp120 and Gag - <AUTHOR> https://www.biorxiv.org/content/10.1101/2020.01.30.927871v1?from=timeline <comment><USER2> The scientific claims of this preprint are almost certainly false.

[https://theprepared.com/blog/no-the-2019-ncov-genome- doesnt-...](https://theprepared.com/blog/no-the-2019-ncov-genome-doesnt- actually-seem-engineered-from-hiv/)</comment>


Show HN: Tool for Visualizing Spread of Infectious Disease - <AUTHOR> https://worsethanflu.com <comment><AUTHOR> This is a simple tool for visualizing how massive the impact if minor behavioral changes can be in the spread of infectious diseases. This model is mostly based off of the math discussed in 3Blue1Brown's video on exponents and epidemics.

[https://youtu.be/Kas0tIxDvrg](https://youtu.be/Kas0tIxDvrg)

There are tons of ways this model could be improved, so please feel free to contribute.

[https://github.com/ralusek/worse-than-flu](https://github.com/ralusek/worse- than-flu)</comment>


We are a spectrum of jobs, not just one - <AUTHOR> http://rachelbythebay.com/w/2020/08/14/jobs/ <comment><USER2> It helps to read her previous post on the topic to understand her point. She complained about being accused of focusing too much on problems of scale as an ex-Google/FB engineer. And she suggests her colleagues don't have the engineering chops or desire to dig deeply into a problem the way she does. I don't think the author understands her colleagues motivations. It may be the case that some of them are "vendorops" coders but I suspect it's far more likely that at a company with resources like FB or Google, which is to say near infinite resources, you can dig into such problems regularly. At a smaller company such technical deep dives may be intellectually gratifying for the coder but may not be worth the limited resources of the people who pay you. And you literally need to grab some off the shelf libraries and code on the company's domain problem to save time & money.

<comment><USER3> I find the idea that "engineering" is really about BIG SCALING really tiresome. Sure, careless throwing together of random libraries, packages, and stack overflow snippets goes against sound engineering principles, but so does nearly everything Google does (I would say "everything" but they do employ careful engineer Junio Hamano, though I'm pretty sure he gets to set his own culture himself).

<comment><USER4> This is a byproduct of the engineering culture being co-opted by the cult of agile.

For some domains, the 80% solution is perfectly fine to launch with. For others, it is quite sloppy and you end up with paper cuts in normal use. Problems arise when you, as a consumer of a library, expect a 100% solution and discover it's only an 80% solution. Worse, most libraries do _not_ tell you what design decisions were made.

</comment></comment></comment><comment><USER5> Ghetto-izing code reuse in programming as "VendorOps" and associating it with the Peter Principle seems like a great way to discourage code reuse and reward people who would rather rewrite code unnecessarily than read someone else's existing code (notoriously hard). Do you really want to make it a badge of honor to reinvent the wheel?

I also would venture this will further marginalize people in tech who are already marginalized. There's enough hierarchy in programming already (and not particularly correlated with skill). IMO!

Also: the position (my summary) "People who disagree with my last blog post don't REALLY know how to program and are covering up insecurity over their own incompetence" is an awfully convenient one to take. Maybe this is not as objective an assessment as it could be.

<comment><USER6> > _I also would venture this will further marginalize people in tech who are > already marginalized._

Extraordinary claims require extraordinary evidence.

I'd venture that if you're going to say, "suggesting this marginalizes people," you should back it up with why you think that. It does no good for anyone to say something like that (and in doing so, heavily imply that the person making the statement is some kind of icky paraiah) and leave it at that.

<comment><USER2> It's clear the author of the original post is taking an elitist stance on what it means to work as a coder and trying to brand the work of others as less important & give it a different job title. Essentially saying "a real programmer does the job in this specific way I say a real programmer does." It's not the kind of attitude that benefits anyone. It's the kind of attitude that does push people out in an industry already with a reputation for pushing people out.

<comment><USER7> The irony is that I'm sure the author experienced elitism and discrimination when she started her career in software development and now doesn't realize she is propagating the same.

<comment><USER2> Yea exactly, she seems to have reached a level of comfort with her technical proficiency and years of experience that she's not even seeing how this kind of talk can be discouraging to a junior who doesn't have the depth of knowledge she has.

</comment></comment></comment></comment></comment><comment><USER8> My takeaway was that "software developer" is not a very useful job description anymore. CRUD, web dev, games, HPC, embedded and other fields require vastly different skill sets. Changing between these fields can be like starting your first job out of college, learning to use not just different tools but also focusing on very different priorities.

(" _$language_ developer" is only slightly more useful, especially for languages which are used across many different fields such as Python (web dev and science), C# (web dev and games), C (games and embedded), etc.)

The article revolves around the continuum from building everything yourself to importing a third party library whenever it can speed up delivering the current feature just a little bit. It's pretty clear by now that the many software development fields fall into different parts of that continuum.

<comment><USER9> > "$language developer" is only slightly more useful

I would argue that this is not a useful distinction at all. Any good developer should be able to pick up any language quickly. At the companies where I've worked, even the interns have no expectation of knowing the language before they're hired, and the vast majority of them learn quickly enough to ship useful code within their ~3 month internship.

<comment><USER10> _> Any good developer should be able to pick up any language quickly._

I see this repeated very often without support, and I think it should be challenged. In my experience there are cases where it's true, and cases where it isn't.

Actual example: I have met highly competent software engineers who were (primarily) excellent Python programmers. They knew OOP well, they didn't typically over-abstract, but they could still leverage modular code for reusability, they tested early and often, they could dig into an existing codebase and maintain it, they could critically and constructively review others' code, they had a deep knowledge of the Python standard library and various domain-specific frameworks, etc. They were really good at all of this.

But by their own admission, they were crap at C++. They didn't really know memory management at all, and they didn't really get the whole "ethos" of C++. Moreover, they periodically tried (and failed) at picking up functional programming.

Now I believe if they were sufficiently motivated they could eventually pick these languages up. But they wouldn't "quickly" ramp up on a production codebase written in a C++ or Clojure. The idea that they're not a "good developer" because they wouldn't be able to quickly become productive in one of these radically different languages is therefore incongruous to me. I'm sure they could dive into a Ruby or JavaScript or even Java codebase. Or maybe C++ if it was strictly modern, 17+ and avoided raw pointers like the plague. But in general, no. It would take a lot of time, because some languages come with a lot of baggage that aren't just about the syntax. For someone who had always relied on Python's PIP, for example, the process of vendoring and importing C++ header libraries is already an obstacle.

The reason I'm going on about this is because it seems like received wisdom and is often stated as an accepted aside, but I really think it needs more nuance. Otherwise we run the risk of defining "good" software engineers by what is perhaps just a no true scotsman.

<comment><USER11> I think you'll find many professional C++ developers say they are crap at C++. It isn't a reflection of their abilities

<comment><USER12> Maybe they say that they don't master the language. If they're crap at it they'd either get a different job or eventually get fired.

<comment><USER11> Effectiveness at using a language =\= effectiveness at implementing useful things in it

</comment></comment></comment></comment></comment></comment><comment><USER13> The title says "spectrum," but a lazy read of the content could suggest that it is a dichotomy that is being described.

The situation described by the author is definitely a spectrum, however. I currently find myself in a position that is a bit far for my liking toward the "VendorOps" end of the spectrum, and I find the name given to this spectrum by the author to be immensely useful.

I've previously defined the spectrum to myself as a "build vs buy" spectrum.

My current job is not exactly "VendorOps" in the complete sense described in the article, but it is a bit far in that direction along the spectrum for my liking, I write and architect code projects, I write unit tests, build and deploy it all within CI/CD pipelines that I myself have built and designed.

But it's all in the service of gluing 3rd party software and vendor implementations together, and I do most of this work myself, with little interaction or overlap with the one other developer that is employed full-time at our company.

Much of my previous experience building what I would describe as "Building Proper Software Projects Together With A Team." And I miss that, and will seek that out in future roles. And having a proper (and publicly defined) name for this concept will be immensely useful.

<comment><USER14> The problem is having a proper and publicly defined name for the concept could piegon hole you. It might make it harder to escape in this world of hyper- specialism.

</comment></comment><comment><USER15> One of the primary reasons I'm trying to move on from being a software engineer is the expectation that I'm supposed to be fluent in dev-ops type work as well. That domain, for me, is something I have absolutely no interest in, and not much of an aptitude for.

The problem is that managing deployed environments is a completely different skill set and problem domain. Is it complementary? Sure. Useful to have? Yes. But it's ultimately orthogonal. I can still write great software without having to give a shit or know much about how our AWS environment is configured, much less do that work myself.

Being a programmer is a spectrum, yes, but it's multiple spectrums. Build vs configure is one. Product focus vs technology focus is another, one I happen to land much closer to the product side. Unfortunately, I think the pendulum is swinging the wrong way for me on that one, and it's soon going to signal the end of my programming career.

<comment> non-entity What are you moving towards, if I might ask?

<comment><USER15> I just took a job that should put me on a management track, but I had been fishing for product jobs as well. I think one way or another this will be my last programming job.

If the mgmt thing doesn't work out, (the opportunity I'm expecting doesn't open up, or I just find out it's not a good fit for me), then I'm not sure what I'll do.

</comment></comment></comment><comment><USER16> I once told a friend of mine that I find "high level thinking" easy. He scoffed at me asking: "how is that easy?"

In my job, high level thinking is that you look at a diagram with at most 10 different concepts that you already vaguely know, and on a high level that is good enough.

For example (I'm making this up):

\- You have a client sending a request

\- Which has a server receiving it that relays the request to the specific service

\- But before that happens it is sent to the auth service and the auth service responds back to the server that the user is logged in

\- The server then relays it to the specific service that the request needed to go to

\- That particular service needs some info from yet a different service

\- That different service sends it to the service

\- The service sends everything back to the service

\- The server does some final serialization (e.g. no silly fields should leak to the client) and sends it to the client

This is the most elaborate example I could think of, most of the time it's a lot easier, but I also find this type of thinking easy.

He responded with: oh that's not what I meant with high level thinking. In our case we need to know specifically: what protocols are being used (is it TCP or UDP, why?), how do services make each other known (e.g. broadcasting?), what component lives where in the world? And so on.

It turns out that my thinking was too high level and relatively useless in the field that he works in (he doesn't have anything to do with web dev and does something more low level, more performance related and more network related).

So that was quite an experience for the both of us that we meant something different with "high level" and that statements such as "I find xyz easy" can come across as very arrogant to the other person because to them you're kind of saying something impossible.

<comment> mkr-hn It seems like a lot of disagreements stem from assuming shared definitions.

<comment><USER16> That statement cuts so deep. In my experience, this is true for all communication. I've experienced multiple times that I'm not speaking the same Dutch (native) or English (second language) as the other person and it's always quite an upsetting realization.

</comment></comment></comment><comment><USER17> If it is a spectrum, why keep insisting to put arbitrary labels on parts of it.

Every job has a different combination of tasks that make sense to be externalized and those that don't. Even the most NIH people will draw a line somewhere and don't do everything from scratch. And the combination changes for the same job over time as the product/project/company evolves.

Trying to capture the exact breadth of a given job in the title alone is in my opinion bound to just lead to endless bikeshedding.

But I'm wondering, if, long term, it ceases to be a spectrum and becomes clearly distinguishable areas of people writing the infrastructure, libraries, frameworks etc. and those that combine them to the final product.

<comment><USER9> > If it is a spectrum, why keep insisting to put arbitrary labels on parts of > it.

Yeah the title of the article is "spectrum" but the contents are about a dichotomy.

<comment><USER18> A spectrum can have sharp peaks.

</comment></comment></comment><comment><USER19> I never comment on Hacker News posts but I found this blog post to be so insightful that I had to give my two cents. VenderOps really is a different job and as a "senior" dev in my career I can say that it is a job that I would happily take at this point. I work for a small startup and there is no end to the AWS, Docker and K8s shenanigans we are called on to do day in and day out. The problem is no one wants to volunteer to do this kind of work so the CTO (the most experienced engineer on our team) ends up doing most of it himself. There are paid consultants who will gladly come in and Terraform all your shit but we don't hire them. While some of us may not consider that "real engineering" these professionals are essential to the success of your startup. Once they put the pieces in place then your devs can run with a fully automated CI/CD pipeline and deliver the features your customers want. Then as adoption starts to take off you get into observability, Prometheus, Grafana and the five nines. This is the point when the agile rock stars start to burn out or bail and the need to bring in experienced SREs becomes inescapable. This is the VenderOps state and it is the pit of success you want your startup to be in even if you yourself have no interest in partaking in it. There will always be a place for brilliant people who need to work and the hardest problems but let's face it a lot of us are not that. I know I am not. A lot of us are journeymen and women who just want put their kids through college and hopefully retire comfortably.

</comment><comment><USER20> I don't quite understand why we need to invent an new word for it? There are people who program and optimize all day and write clever one-liners and create libraries and frameworks only they understand (programmers), and people who collaborate & have a holistic view on software development, and as a result actually get stuff done in a solid way (engineers).

Yes, you can tell what I think about this article (and the one before it).

If your goal is to ship a product, there is no reason to reinvent anything that is not your core business. I don't see the author of this article writing their own OS from scratch, so why stop there? Why should all the auxiliary libs and frameworks be created from scratch? Because they don't like all the communities around the existing ones?[0] If everyone around you is the problem...maybe its you who is the problem. I've never had any pull requests with fixes or minor features rejected from upstream, so my view may be biased.

I prefer hiring and working with people who understand the value of contributing to OSS instead of building their own little castles.

[0] [http://rachelbythebay.com/w/2018/10/09/moat/](http://rachelbythebay.com/w/2018/10/09/moat/)

<comment><USER21> Couldn't one argue that most open-source projects are born as someone's "own little castle"? If people didn't build their own little castles, we wouldn't have, for example, UNIX.

I agree about hiring and working with people ("engineers") who take full advantage of existing tools and libraries; and can contribute to well- documented and battle-tested libraries in the community.

But, as someone who (also) fits the description of a "programmer", I see the value in building our own little castles for fun and profit, to create libraries and frameworks for our own purposes. If existing solutions don't quite do the job, someone has to start these well-documented and battle-tested libraries to benefit the community - even if "only they can understand" it at the beginning.

Perhaps the contrast and tension between these approaches are about the inherent risk of innovation. In a team environment, we don't want people inventing their own language or operating system from scratch - unless it directly contributes to the core business, which is rarely the case.

For the largest tech companies, they can afford to risk the investment into innovation, to develop and maintain their own languages, frameworks, and libraries - if they bring competitive advantages. This caveat is often unclear though, whether this (re)invented thing actually delivers.

<comment><USER20> Absolutely. Doing the right calls here is very hard, and takes a lot of experience. Btw - I'm not against building your own castles (I love doing that, esp. in my free time) - I am just a bit triggered by the previous blog post arguing unconditionally for it, and now the next one even saying these are two (or even more) different professions. I don't think that is the case. I think we need to understand the contexts, to know when each of the approaches is a likely better fit. Sometimes its very clear, and sometimes you won't know until much later. That's ok. I think it is important to document why a route was chosen, and evaluate if it is still the correct one, once more facts are available, or the environment changes. What I really don't like seeing is ranting about a chosen approach, without informing oneself first about how the decision was reached, and broad generalisations.

Writing your own software, or just importing a lib, and the resulting side effects such as huge amounts of code to maintain or dependency hell, are tradeoffs - they are neither good nor evil - it all depends on the context.

I'd love to see an article from the author drawing from their experience on making that kind of decisions.

<comment><USER21> > I'm not against building your own castles (I love doing that, esp. in my > free time) - I am just a bit triggered by the previous blog post arguing > unconditionally for it..

Yeah, I totally hear you. God knows I've built not only "castles" but immense, complicated and unsustainable architectures (or balls of spaghetti); deadend frameworks that started deprecating the moment I wrote it; under-documented or -tested (or not at all!) libraries with unclear interfaces..

As much I love creating things from scratch, experience has taught me to be cautious and conservative when deciding to do so - especially in a company/team environment. It's almost always better to research first, study what exists in the ecosystem/community, and use available tools and building blocks.

Many articles get posted on HN that describe how and why a company decided to build their own database, operating system, language, framework, or library.

It's not as exciting to read or write about using "boring technology" to build stable, reliable systems with a decade-old, tried-and-tested framework. But this latter is, and should be, the standard approach: mostly "engineering", with just enough "programming" to glue and orchestrate it all together.

</comment></comment></comment></comment><comment><USER22> I guess I am stuck trying to understand if the assertion being made here is that folks who use a library to connect to PostgreSQL are not really writing software, but maintaining vendor garbage.

<comment><USER23> Worked with a guy who made pretty much exactly that assertion.

We discovered in the course of his time on the project that he was _physically_ incapable of maintaining other people's code (which he knew, going in, that he'd be required to do).

So he _constantly_ argued that code that existed was fundamentally broken, and needed to be rewritten.

He wasn't on the web team, which I ran, but he often gave me crap about using Rails when I could just "write it all myself and it would be so much simpler". I did a class for the group describing Rails, and what it gives you, and why you'd use it.

His response? "You're not programming, you're just configuring it!". Sigh.

</comment></comment><comment><USER4> I'd argue when a developer moves toward the mid-career mark, some will discover that they no longer want to be gluing code together all the time at their job. That is expected and healthy for some. They're not better devs like the article implies. They just need something different.

We don't talk about this enough because it feels taboo to even imply that this overly "communal" form of development isn't cutting it for some. We're so hyper-focused on vague values of community and accessibility when career development is intensely personal.

I said no to webdev in 2012. And it has paid off significantly for me.

</comment><comment><USER24> This is a really helpful distinction. I have worked across a few different jobs with differing expectations across this spectrum. The really lean startups want to get places quickly and blending together a dependency soup is usually the most efficient way to get there. More established companies sometimes have the resources to allow more R&D and home-grown libraries and tools. They are really different jobs in a lot of ways but we haven't done a lot to distinguish them in how jobs are presented.

I wonder if this distinction is going to be even more helpful as the low- code/no-code trend takes off and more jobs can be done by those with fewer skills.

<comment><USER9> > The really lean startups want to get places quickly and blending together a > dependency soup is usually the most efficient way to get there. More > established companies sometimes have the resources to allow more R&D and > home-grown libraries and tools. They are really different jobs in a lot of > ways but we haven't done a lot to distinguish them in how jobs are > presented.

IMO the correct thing is to hire people who are good at both and know when to use which approach. Otherwise the learn startups will never be able to transition to established companies. And likewise, the established companies have many problems to solve that don't require home-grown tools, so you don't want people who only know how to start everything from scratch.

<comment><USER25> Maybe seed round/earlier you can't hire those folks? In my experience, the engineer who liked being on an early team does not enjoy being part of a 100+ eng org. So dependency soup engineers churn and you end up with a different type of engineer when they transition to a real company.

(Clearly this is one perspective. It would be great to hire the best engineers from day one but sometimes that's not practical.)

</comment></comment></comment><comment><USER26> I agree with her that lots of libraries on the internet are bad. But expecting companies to write their own is worse. I remember years ago that everyone wrote their own C string libraries. There were hundreds of them. Most were bad. Then C++ matured and provided a pretty good (and safe) standard string class. Having that standard library was way better than everyone writing their own (mostly bad) string solutions.

So it is OK to use libraries, but use well regarded ones that have large, established communities. And don't use libraries for simple small things that your team can do themselves.

Her point about depending on others to get your company's work done is a valid one and should be minimized as much as possible. This is why I prefer open source, standard languages and why governments still use C and C++. They are ISO standards that will be around and stable for decades.

<comment><USER10> I think what it comes down to is the way these libraries are used.

In my experience, the trend of software development over time is division of labor into specializations for hard engineering problems, while creating paved roads and happy paths for good generalists. I use the term "generalist" charitably here, whereas the author's description feels (to me) to be a little disparaging.

To your point, I think it's good we have this trend in software development. Having all these libraries is a net good which saves time and results in fewer footguns. I believe the problem she is describing is more productively considered by looking at it as a problem of using a vendored library in a way that it isn't designed to be used (i.e. "driving off the paved road"). There are often good reasons to drive off the paved road, but you need to really understand your problem and the solution space to pull it off competently. I think the author's experience is therefore caused by two things:

1\. Businesses which are not at Google and Facebook scale, and thus can't afford to build much in-house from scratch.

2\. People who try to duct tape APIs together without a strong understanding of the underlying limitations of each library, and the design boundaries of each.

<comment><USER27> As one of the generalists, I'd like to add to this comment. I see two kinds of problems: open and closed. Closed problems are sort of "traditional" engineering problems. They're math heavy, they have a precise, indisputably correct answer, and they probably require some kind of algorithm to solve. These are very challenging and interesting problems to dive into, and I certainly have some interest in them, but they are not my primary interest. I like to use software to solve business problems, which sometimes involve a closed element but more typically are open. They involve human beings and have fuzzy definitions of correctness. I like understanding my users and the weird little worlds they inhabit and how I can make their day a little better. To do that, I need the sorts of tools that the closed problem engineers provide. Now you can absolutely be a great open AND closed problem engineer. I'm studying some more math and algorithms to try to improve at that. I'm also willing to dive in and debug some complex messy library code when I need to, and I do agree it's my job to evaluate the maturity and reliability of a library before I add it as a dependency. All that said, I take issue with the notion that I'm not a good engineer if I choose to outsource some of my problems—especially these closed problems that require a lot of work and experience and attention. Software is not special. In business, every decision involves tradeoffs and opportunity costs. It's completely unhelpful to take potshots at engineers making a conscious choice not to tackle some problem when they can have it solved by someone else.

All of that said, you're obviously correct that some people just paste together unstable things they have put forth zero effort to evaluate, and that's a problem.

</comment></comment></comment><comment><USER28> Having worked in a FAANG and in consulting for normal companies. Yes, vender ops is the mainstream model that bings most value for normal companies. However, it's a bit disenginous as even in FAANG stuff was mostly built from infra Lego sourced from someone else's engineering. So there was a quite a high amount of internal vendor's too, but the quality was much less hit and miss. But it's really only a path the FAANG can walk, being absurdly expensive. I am comfortable in both worlds, deep engineering is fun, but sharing the powers broadly has more positive impact overall I think.

</comment><comment><USER29> So instead of engineers making informed decisions on buy-vs-build taking into account uniqueness of requirements, maturity and stability of the ecosystem, and resourcing constraints, we should say one group doesn't know how to do the latter and should stay in their lane and only take jobs where they are guaranteed not to have to build anything?

</comment><comment><USER30> Further specialization reduces job mobility and I believe is one of many factors in wage stagnation.

</comment><comment><USER31> A role encompasses a set of responsibilities. When we try to make the responsibilities too narrow it creates lots of space for myopia. Narrower still, and the person starts to guard it jealously, because it's all they have.

We got rid of most of the DBAs, Architects, and QA. Any of those would be better than having someone whose only job is wrangling third party code.

</comment><comment><USER32> As a Nix user, it's depressing to see that the rest of the industry due to terrible package managers has fallen into terrible trade offs between "not writing the same thing again and again" and "understanding what the hell is going on and not being an alienated pretender".

Really a bummer; this is the rare case of a social issue that _does_ have a technical solution!

</comment><comment><USER33> Didn't even bother to describe the two different jobs. What a waste of time this article was.

</comment><comment><USER34> Now all we need is an acronym to describe the jobs we have.

<comment><USER35> Maybe it's time to revive and refresh the Geek Code:

[https://en.wikipedia.org/wiki/Geek_Code](https://en.wikipedia.org/wiki/Geek_Code)

</comment></comment><comment><USER36> Software Supply Chain engineer?

<comment><USER37> Technical Accountant

</comment></comment><comment><USER38> So DevOps then?

<comment><USER39> It is about replacing the "Dev" part with "buying/downloading" thus VendorOps.

<comment><USER22> Pretty wild assertion that using rust crates eliminates development.

<comment><USER39> I can imagine a big Rust project where there is person who does nothing but updating dependencies. Trivial changes in the code he will do but most is delegated to the developers. The job includes:

* Analyze dependency updates for breaking and performance impacts

* Coordinate the cleanup of deprecated API use

* Feedback to upstream

* Resolving integration issues (usually by delegation and controlling)

This guy does not write significant amounts of code but will still create lots of commits.

<comment><USER22> As near as I can tell, the post is a response to comments in reply to a previous post which essentially states that the _existence of cargo_ is bad because there are bad libraries available.

This post further asserts that folks who like the fact that libraries are easily available are "not very good at something being discussed" and have "Peter Principled" themselves. It also states that they are, "almost rational."

What you're describing is an under-performer, or perhaps someone who is working specifically in a maintenance capacity (likely with a title that reflects that!). I don't think that is what the original post is talking about, but perhaps I have misread.</comment></comment></comment></comment></comment>


State of U.S. Salaries Report [pdf] - <AUTHOR> http://get.hired.com/rs/348-IPO-044/images/Hired-State-of-Salaries.pdf <comment><USER2> Whenever a statistical report uses averages (and no medians anywhere), I always look for a sample size, since it gives an indicator on the potential variation for the true average. (Error is inversely proportional to square root of sample size)

So I checked the methodology and found something odd.

> The salaries included reflect more than 80,000 interview requests and job > offers from the past year

Why are interview requests and job offers _lumped together_? Wouldn't there be _disproportionally_ more interviews by definition? As a result, it's very hard to gauge the sample size of the salary data.

<comment><USER3> Hi my name is Jessica and I am the data scientist at Hired who pulled the numbers for this report.

The way the Hired platform works is that companies must submit an initial salary offer when they start the interview process, and so all interview requests have salaries attached to them. Of course these offers can be negotiated later, but for the vast majority of our hires on the platform, the final base salary is equal to or higher than the initial offer given at the interview stage. Therefore we feel confident that this salary data is representative (if not a slight underestimate) on 2015 salaries for software engineers.

<comment><USER4> Give me a break. I have been using Hired for almost two years and everybody knows that number is made-up bullshit. It means _nothing_ and everybody knows it!! You're slanting the numbers to make Hired more attractive. I love Hired. The company has totally changed my life for the better, and I could not be happier using it, but this is BS, and anybody that's used the platform knows this number that accompanies interview requests is almost nonsequitur to what actually happens.

<comment><USER5> Unnecessarily rude and combative. Flagged.

<comment><USER4> Well, sometimes the truth hurts.

<comment><USER3> This is Jessica, Data Scientist at Hired again...

I'm glad you've had a great experience on Hired and that it has changed your life for the better.

I'm surprised that your experience is that the initial salary offers (at the interview request stage) are significantly different than your final salary offer, because I can tell you that this is not the experience of most people on our platform. The majority of the final salary offers are equal to or greater than the offer given at the interview request stage. On average the final salary offers are slightly higher than the interview request offers across all Software Engineering Hires on the Hired platform.

<comment><USER6> Are the base salaries of each applicant shared with interested companies? Or are they used to match a company with a potential candidate?

<comment><USER4> Are you referring to the "base salary" on an applicant's profile? That number is created/edited by the applicant and visible to everyone that can see the profile. AFAICT that number has an effect on the "potential salary" number companies give to applicants, but I do not believe there is an internal matching between applicants and companies based on this number.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> "Forgetting cost-of-living adjustments for a moment, our data indicates that there are advantages to starting your career in San Francisco"

If you are relocating to the bay area with a family (say on a visa that doesn't allow your spouse to work) and your offer is 130K$, no matter (almost) where you live, stay there!

<comment><USER8> Why? $130K is a respectable salary, nearly twice the median for the area. Sure, you couldn't live in a luxury home in the city, but with $130K you could live in the outskirts of the Bay Area and commute in. Totally do-able.

<comment><USER7> Depends on what you mean by "outskirts of the Bay Area" and what is the school district.

Say you have 2 kids under 5, you have to pay around 1200-1500$ for education for each of them, 3200-3800$ is rent.

Doable? Not really

[edit] Even if your kids are not in school yet, good school district means better neighborhoods (for most parts).

<comment><USER8> I live about 50 miles from work (~2 hour commute each way) and my monthly housing cost is around $2000. It's totally do-able. 2 hours is a little on the high end for a commute, but it's not the end of the world.

<comment><USER7> I have 3 kids (6yr, 4yr 3mo).

I can't imagine a scenario where I am just sitting in my car for 2 hours on the way to work and on the way back.

Almost to the day 2 years ago I wrote this post [http://avi.io/blog/2013/12/06/why-i-will-never-work-out- of-a...](http://avi.io/blog/2013/12/06/why-i-will-never-work-out-of-an-office- again/) still super relevant today.

I don't know your situation and if you have kids or not, but I will never be able to do what you do. ever.

<comment><USER8> Yea, I've got a 3 year old who gets plenty of daddy time at night and on the weekends. Can't say I _like_ the commute, but it's not as horrible as all these dramatic replies make it sound. I'd definitely move closer to work in a heartbeat if the South Bay or peninsula was affordable.

<comment><USER9> > ...it's not as horrible as all these dramatic replies make it sound.

I do _sincerely_ hope that you're one of the few who can _happily_ give up half of 5/7ths of his leisure time for his family. I've never personally known anyone -family man or no- who can endure such a lengthy daily commute for more than a few years.

Something just wears away at you until -one day- you realize that you're deeply dissatisfied about something... and eventually come to realize that it's your long-ass commute.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> "One possible reason for this is the availability of salary alternatives as part of an overall compensation package. For example, companies with less than 200 people are usually in the series b or below stage, and can offer more equity, whereas many companies with more than 500 people are publicly traded and can offer stock packages. Those in the middle have less equity to give and typically aren't publicly traded, so higher salaries may be a way to keep offers competitive"

That's a pretty big caveat, and is a big problem with their data. I'm at a big publicly traded company and my taxable comp is 60/30/10 between salary, stock, and bonus. Comparing just the salary portion with another company where comp is mostly salary wouldn't be very helpful.

I wish people talked more about total comp and less about salary.

</comment><comment><USER11> Due to proximity and similarity of lifestyle, and how crazy things are in the bay, I keep assuming that any minute now companies and engineers will start moving up to Portland in droves. (Well, I wouldn't expect companies to _move_ here, but certainly open offices.)

But looking at available jobs and so forth, that doesn't seem to be panning out. Does anyone have any thoughts about this? Is Portland too small of a city for that, still? It just seems like a no-brainer to me.

<comment><USER12> I'm a Bay Area resident that just got back from my first visit to Portland. It's an amazing city, great food, and pinball in every bar. But the weather sucks (I'm still wet), and it's missing the critical mass of tech that the Bay Area has.

The tech scene reminded me of nearly any other similarly sized city in North America. One or two interesting employers (New Relic, Puppet Labs), and the rest is enterprise.

And even if Google, Facebook, Apple, and all the other smaller interesting companies moved there overnight, the cost of living would skyrocket overnight too, blowing away Portland's main advantage.

And if you thought the hipsters' resistance to tech in SF was bad, I feel that Portland's would be worse.

<comment><USER13> I interviewed at one of the two companies you mentioned and their total comp package was about equivalent to my signing bonus at a company in Seattle. I like Portland, but not enough to take a 3x-4x hit in compensation to move there.

I know of one company that opened an office in Portland because compensation is so low there. That's great for them if they can hire people at local rates, but it's not really appealing for people who have the flexibility to relocate anywhere.

</comment></comment></comment><comment><USER14> For those interested... here is the blog post: [https://blog.hired.com/hired- digs-deep-software-engineer-sal...](https://blog.hired.com/hired-digs-deep- software-engineer-salaries-us-uk/). It also has a UK report.

</comment><comment><USER15> It would be interesting to see the breakdown on average salary vs experience. As someone just starting my career it would be interesting to see how it compares to having 5 or 10 years experience.

edit: the UK report has that breakdown, not sure why it was omitted from the US report.

<comment><USER16> I don't think hired.com really takes candidates who are just starting their careers, so their data will be almost all mid-career folks.

<comment><USER17> They are also skewed as to the specialties they can effectively place. Their clients seem to over-represent web and mobile companies and under-represent the rest of the industry.

</comment></comment></comment><comment><USER18> I've always found the Robert Half salary guides to be the most comprehensive guides available:

[http://www.roberthalf.com/workplace-research/salary- guides](http://www.roberthalf.com/workplace-research/salary-guides)

<comment><USER19> In your opinion, how well does their data apply to the tech startup scene?

There's, of course, many factors that make this type of employment quickly changing, quite dynamic, and different from standard corporate employment.

<comment><USER18> I've found their statistics to be focused on a broader base of employers than just startups, so I'd expect salaries in their data to likely be higher since they don't factor in equity. You can use this formula for adjusting for the value of the equity:

[https://news.ycombinator.com/item?id=10529567](https://news.ycombinator.com/item?id=10529567)

<comment><USER20> Interesting, I would have gone the other way (assuming salaries in data were lower), as I think there's quite a bit of inflation in startup job offers.

Also, I wonder how best to account for stock units vs options as far as equity awards go.

<comment><USER21> >I think there's quite a bit of inflation in startup job offers.

I think you're living in a willfully ignorant echo chamber

<comment><USER20> I don't think I understand this comment enough to refute it...

Are you saying that there startup job offers aren't inflated? Or that they are?

Are you assuming I live in SV?

<comment><USER9> > Are you saying that there startup job offers aren't inflated? Or that they > are?

Aren't. Conventional wisdom is that folks who work for a startup take a _significant_ haircut vs. working for an established company.

<comment><USER20> Thanks for clarifying.

I made the comment because I find that startups (or the recent brand of startups with crazy valuations and relatively cheap operating costs) are the ones that push 80K/90K+ salaries (at the very least) for people straight out of college and nice office perks.

A few years ago (and probably still now), people could get hired by big companies like HP/Dell/Intel/Oracle (or other big companies whose main competency isn't necessarily computing) with relatively low salaries (lets say 60K or 70K). This only really applies to recent grads/relatively young developers though, I guess.

I see now that I had it backwards.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> It'd be nice to see some cities in the great middle like Phoenix, Albuquerque, St. Louis...

</comment><comment><USER23> "Start with the highest number possible and you'll get offers with those numbers or higher in the future". Sure, that's logical.

That said, how long are you going to sit in San Fran before you transfer to another city to realize the benefit of that salary change in real terms? What's the cost of doing that? It seems like a weird overall conclusion to draw. If their goal is for everyone to have a job they love, they should start wherever the work is that they love at the best salary possible (I would argue that the best salary possible should not take geography into account)

</comment><comment><USER24> Is the fact that starting your career in San Francisco nets you better offers elsewhere in the future a valuable statistic? There are a lot of top tech companies there and so presumably luring people away from them costs companies in other locations more money. I feel like this stat is really just saying work at a good company and then your next offer will be a lot higher

</comment><comment><USER25> Interesting analysis, but would have also loved to see a breakdown of salary by years of experience. "Average salary" doesn't tell me much about how much I can reasonably expect to be making in those cities - how many of those data points were senior vs junior people?

<comment><USER3> Hi my name is Jessica and I am the data scientist at Hired who pulled the numbers for this report.

Hired.com does provide this information. You can use our salary calculator to get more detailed information about what salary you should expect based on your experience, skills, and location: [https://hired.com/salary](https://hired.com/salary)

<comment><USER25> This is great, thanks!

</comment></comment></comment><comment><USER26> Why is UK (London) salary so much lower than that in US (New York and SFO)?

<comment><USER27> Having recently moved from Waterloo, Canada to London, I can say that some of it "just because" (market effects), and another part is the "benefits" you get here (compared to the US): free health care, cheaper university tuition, etc.

Have a look at banking/finance salaries in London, they are very comparable to SF/NYC.

EDIT: here are some highly scientific and factual polls on HN about London salaries from recently: [https://news.ycombinator.com/item?id=5804134](https://news.ycombinator.com/item?id=5804134) [https://news.ycombinator.com/item?id=10498333](https://news.ycombinator.com/item?id=10498333)

</comment></comment><comment><USER28> Does Hired.com not have any data for software engineers in Miami?

<comment><USER29> Not yet. We plan on launching in Miami in the near future.

<comment><USER30> What about Portland?</comment></comment></comment>


China Stole F-35 Designs - <AUTHOR> http://mashable.com/2015/01/18/f35-joint-strike-fighter-snowden/

<comment><USER2> Via a trojaned excel file which exploted one of the endless 0days in flash.</comment>