I'm in your category as well. An unfortunate side effect of this is that I think I'm kind of terrible at technical interviews though.
3,208 karma · joined August 22, 2011
Quick tip: For people who work in a company where they don't necessarily have control over their own time: schedule the living out of your calendar. Book endless meetings with other programmers, then just sit there and do work. "Q2 Backend Architecture Review: 4 hrs" can just be a few people sitting in the meeting room programming. It's crazy the power of blocked out time on your calendar to a manager who otherwise sees an empty day.
I don't think I quite captured everything, I might take another shot at this again sometime.
1. There usually are just a few critical pieces to any project. You should try to start with those and get them locked down first. These can be critical because they are either technically unproven or just plain difficult. Once you know the hard stuff is handled then you can fill in the easy stuff from there on out. (You'll also feel less inclined to fancy-up the easy stuff, in my experience. That's another source of trouble).
2. Use quality tools, become an expert with them, and hold on to them as long as you can. What does quality mean? To me: reliability, stability, and efficiency of both my time and the machine's time. Knowing how to do something because you've done it before, seen the problems and worked through them, and come out the other side, is _huge_. Rarely rarely rarely, a new technology comes along that overwhelms the advantages that hard won experience provides, but it's super rare. This is a whole topic in itself, but in my 20 years the list of situations in which something new clearly brings enough benefits to switch are surprisingly rare. Off the top of my head (and just to make everyone mad in one easy sequence): moving to Java from C/C++, Hibernate ORM instead of endless hand crafted SQL, S3 instead of a probably-about-to-be-full attached volume, Heroku instead of running my own machine, Unity instead of my bad custom game engine, and most recently Flutter instead of native Android/iOS (although this one is still early days).
3. Be honest about what you're actually spending your time on, and optimize for that. A lot of the fancy programming languages of recent years have been spending huge amounts of time optimizing what, for me, weren't big usages of my time. I realize this is vague, but an example for me might be Scala. The stuff that they were improving looked fancy in examples, but it didn't make a material difference to me (as a Java programmer) in what I actually spend time on. It also came with a bunch of downsides, which is itself worth an entire post.
4. Don't be afraid of simple looking code. It might be slightly embarrassing to check in, but it's probably going to be clear how it works to you any other other person who needs to read it in the next few years. The urge to appear smart in the way your code looks can be deadly.
5. Be specific about the upsides you expect when examining a new technology. Are you looking to work faster, are you looking for performance in a specific category, etc. Failure to properly define your criteria leads to adopting things that are a bad fit for your situation (helllooooooo microservices) or at least provide minimal benefit in return for the _huge_ expense of throwing out experience in another technology.
I'm pretty sure there's lots more examples, but that's all I got at the moment. I will add more if I think of it. I guess this should all be a big blog post at some point as well, if it's something people find interesting.
I used to assume that the "10x engineer" was 10x faster at the programming/typing part, but it turns out it's more like identifying the 1/10th of the work that actually matters and just do that efficiently. It is also true that there's a lot of experience in both the identification of that 10%, and the efficient execution of it though.
Side note: I have also met a few flat out amazing, natural programmers. These people can also be 10x as productive, but it's in a pretty specific way that should probably just be considered an outlier. My feeling is that the main way for the rest of us to achieve that level of productivity is gain experience, do things simply and efficiently, and learning how to focus on the things that matter.
There is a second question as to whether Windows is still inherently more susceptible to these kinds of attacks (I would guess the answer is yes), but that's kind of irrelevant. The threat exists, why wouldn't you just use Macs or Chromebooks or whatever else? Basically _anything_ other than Windows? Even in the case where you have Windows-only business critical software, just run it in a VM on something else.
There appear to be exactly two reasons to use microservices:
1. Your company needs APIs to define responsibility over specific functionality. Usually happens when teams get big. 2. You have a set of functions that need specific hardware to scale. GPUs, huge memory, high performance local disk, etc. It might not make sense to scale as a monolith then.
One thing you sure don't get is performance. You're going to take an in-process shared-memory function call and turn it into a serialized network call and it'll be _faster_? That's crazy talk.
So why are we doing it?
1. Because we follow the lead of large tech companies because they have great engineers, but unfortunately they have very different problems then we do. 2. The average number of years of experience in the industry is pretty low. I've seen two of these kinds of cycles now and we just keep making the same mistakes over and over.
Anyway, I'm not sure who I'm writing this comment for, I guess myself! And please don't take this as criticism, I've made these exact mistakes before too. I just wish we as an industry had a deeper understanding of what's been done before and why it didn't work.
HN is a very skewed place that's into some very niche stuff. That can be fine, it's good to be interested in new things, but no one should draw too many conclusions from trends we see on here.
Just to poke a few HN bears by way of example:
* Rust will never see widespread adoption. It's just hard and complicated, so seems cool and exclusive. * Lisp isn't gonna happen either, and that's because it's not even a good choice for most problems. It just feels really really cool when you write something in a purely functional way and so you imagine that _must_ mean this is some higher plane of existence. Not really, we've had 30-40 years for this thing to take off, not happening. * Even Erlang, while really cool, is just a super niche thing. If you're making a huge messaging service then definitely go for it, but you're making a website? Choose pretty much anything else.
There's a lot of reasons for all of the above (low average amount of experience leading to long term memory loss for the industry being the big one), but this comment is too long already and everyone's just going to be mad about the Rust stuff anyway.
Admittedly, this isn't the kind of stuff I normally write, so I might be missing something. But since the ramifications of these memory leaks are so severe, I would think the industry would be adapting.
An on-chain contract holds your funds and requires some number of signatures to authorize transactions (for personal use usually 2, i.e. one from your desktop computer and one from your phone). That way at least you know two separate devices would have to be compromised to cause loss of funds. This also allows for interesting key recovery strategies like having a third paper wallet that is also authorized. You could use that as a backup key that would allow authorization of a new key if your phone were stolen, etc.
In my experience, Swift is lacking any particular major improvement over ObjC. It seems like async/await could have been that big step, and Swift probably shouldn't have been adopted until it was in place. Just wasn't worth it.
I realize that's a controversial topic and I know people who love Swift, just from my perspective it was such an enormous cost without enough upsides to justify it.
By comparison, Grand central dispatch is pretty nice on iOS, but I really miss the first class async/await calls. Side note: How did they make an entirely new language for app development (Swift) and not build in async/await support?
Kotlin co-routines seem to be a pretty nice solution on Android, but before that it was a bit of a mess. There was 4 or 5 different ways to do things async, they all interact in super complicated ways with the activity life cycle, and basically nothing is quite what you need.
Side side note: Unity also does a really nice version of all of this with a single event loop and really powerful co-routines. Worth checking out sometime.
I've also heard that this asset might be useful, but I haven't tried it yet: https://assetstore.unity.com/packages/tools/modeling/magicav...
Here are some other awesome things made with it: https://twitter.com/HuntingFluff/status/1046417418459975681 https://twitter.com/Sir_carma/status/1051867299303440384
And in general I recommend following Sir Carma for inspiration: https://twitter.com/Sir_carma
For example, in this article: "the controversial ITER project, a hugely expensive fusion reactor..." There is no doubt this is an expensive project, estimated at ~$20B total cost (https://en.wikipedia.org/wiki/ITER#Funding) However, in terms of possible upsides or even compared to other projects it's _cheap_. Boston's "Big Dig" was $24B for example: https://www.boston.com/uncategorized/noprimarytagmatch/2012/... Which would you rather have? A 1.5m tunnel, or an energy source that would change the future of human civilization?
I am being somewhat unfair here since the Big Dig was a case study of mismanagement and cost overruns, but as a society we should be willing to spend significant resources on world changing research instead of say $22.5B on three new boats: https://en.wikipedia.org/wiki/Zumwalt-class_destroyer
All that being said, the way forward is probably to figure out ways to make fusion related projects smaller in scale and cost. Then multiple attempts can proceed in parallel without all the organizational and governmental overhead. More on that here: https://www.youtube.com/watch?v=KkpqA8yG9T4
Thanks!
This is an honest question, I just don't quite get why there's so much excitement in the comments.
Thanks!
My main goal is to at least have the code run in an expected way and produce an expected result. This doesn't catch everything, but it does seem to catch enough problems to be worth it for the time invested.
Edit: I should mention that I also add tests to cover something when I experience a failure, so it at least won't happen again.
Everything you said in this sentence is a deal breaker for a casual user, and a terrible user experience in general.