I have never formally interviewed for freelancer roles. I don't interview car mechanics or plumbers -- I pay them to fix a problem and expect (sometimes wrongly) that they know their business. When I get a freelancing lead the customer doesn't usually care about my experience, education, age. They want to know if I can fix their business problems. Either I can or I can't. If the customer does try to start an interview with me I change the subject to focus on what problems they need to solve. My job as a freelancer/consultant amounts to quickly understanding the problems, setting priorities, and fixing things. I'm not auditioning for a f/t job.
One brick at a time has been my philosophy for a while and it's worked well. Making a bucket list of life, then turning that into to do lists, then doing the things 1 by 1.
> The only way to actually get things done is to do them, and that will never change.
This is the most blunt, real, and effective advice that can be given.
It is very important to emphasize that daydreaming of doing everything (and all at once), is a dopamine trap! No matter how long one mentally masturbates on a beautiful idea, it’s only through charting a course, breaking the problem down, and going through the motions and the steps to completion, humbly and dutifully, that will yield any results.
Another commenter, unfortunately downvoted, also said something important:
> Never tell others what you gonna do unles you have done it.
This is equally important advice, as it falls in the dopamine trap category.
Namely, refrain from satisfying the creative urge merely by talking about it. Instead, act first, and talk about the results.
Goes without saying, but let’s say it anyway: of course this doesn’t mean that you should hide like a mad scientist; communication is crucial in creation. Just don’t spend all your time talking about all the nice things you’d have done, if you weren’t spending your time just talking about them while leaving them undone.
Also, if the thing you want to make has some sort of personal meaning or cause, that’s a great impetus.
And don’t forget to fail, and don’t be afraid to fail, either. Try, err, try again, err elsewhere, keep moving, keep learning, keep making.
Not really. The only way to actually get things done is to do them, and that will never change. Planning and daydreaming is very satisfying and feels much easier than actually doing, but it's a dopamine trap. Plain old setting a schedule and applying self-discipline is the simplest way forward...
If you can get into the beta, the Jai programming language by Jonathan Blow ticks the box of "no build system required." With how the build system is managed (just running arbitrary code at compile-time that modifies the build process), I can do this 99% of the time:
#run compile_to_binary("name_of_binary");
main :: () {
// ...
}
#import "base"; // my own library that has 'compile_to_binary'
I'll go into depth about what this does, but if you're not interested, skip to the final code snippet.
The above code '#run's any procedure at compile-time (in this case 'compile_to_binary' which is defined in the library I imported). That procedure (really a hygienic macro) configures my 'workspace' to compile down to a 'name_of_binary' executable in the current directory. Any third-party libraries I've imported will be linked against automatically as well.
To do this without a dedicated procedure, just put this in the same file as 'main':
#run {
options: Build_Options_During_Compile;
options.do_output = true;
options.output_executable_name = "name_of_binary";
set_build_options_dc(options);
}
main :: () {
print("This is all I need to build a project\n");
}
#import "Basic";
#import "SDL"; // or whatever...
Then compile:
jai above_file.jai
I've done this for projects with hundreds of files that link in SDL, BearSSL, etc.
The best part is neither of these systems are a requirement to build your project. Running the compiler against a Jai file will do everything I do with my own system (I just like having the ability to configure it in code).
Jai has been a breath of fresh air in terms of "just let me write code," so I highly recommend it if you can get in the beta.
Well, I might be pretty inexperienced, but in our project management class it was explained pretty clearly that agile (=lots of iteration) works best for projects with lots of unknowns (especially with a high risk of unknown unknowns), while waterfall (=no iteration) works best for already well-trodden projects in well-known conditions.
(We were too busy for an agile class or project, only got waterfall, since it is simpler.)
There are only two real issues here: How to pull it off technically, and How much to charge for it.
Price is the thing that's going to kill this deal, so we may as well tackle it first. It will cost your customer ~1,000X the monthly price to get this done. That's 5 figures, minimum, and it should be toward that high side of that range.
And we're done. 90% of the time, a ballpark estimate will realign the customer's idea of off-the-shelf vs. custom software, and you'll either never hear from them again or they'll decide that you know what? It turns out we can actually run off your servers after all.
But what about the guy who you couldn't scare away with your $34,000 delivery fee and bump to the $600/month Enterprise Plan (billed annually up front)? Well, now you have 6 weeks after the check clears to figure out how to deliver.
I've done this with both of my SaaS products, and the process is the same. Take the current version of the app and start lopping things off. All the marketing, pricing, billing, etc. goes. Database gets built from schema and lookup tables populated. Kill the customer registration (after using it to create customer #1 for them), but leave the Team stuff in place so that they can add their own logins. Replace the landing page with a redirect to the login screen. Smoke test it a bit then burn it onto the customer's VM of choice.
If they want to purchase updates with new features, make it expensive enough that you can do this whole process again every 6 months. Personally, I've always sold "maintenance only" contracts that guarantee timely fixes for stuff you broke in the last paragraph, with functionality frozen as of the date of purchase.
But yeah, it's actually quite fun doing the implementation of one of these. And a lot less work than you'd expect. Again, though, it's unlikely you'll ever get the chance to do it for the two customers who are interested today because if you price it correctly, you'll scare them away.
Here's looking forward to the one who ends up pulling the trigger!
I worked as a petroleum engineer running reservoir simulations. While not a "developer" per se, I had to run FORTRAN binaries on a Linux cluster, know shell scripting, run servers, git for code tracking, writing reports in LaTeX, Linux desktop and dependency hell, list goes on. I did this in industry and research (corporate projects, Department of Energy) both as a consultant and full time employee for 9 years counting Internships.
How I got my job: I was an average student in college and can't interview. I've actually never gotten a job I've applied for, but I digress.
I emailed everyone in my home state for a job because I thought I wanted to live there when I was through with school. I lived in a small oil producing state, not a Texas. Long story short, I ended up emailing the lobbyist for the local coal council asking if he knew anyone in the o&g industry in my state and that I was a young college kid looking for an internship. He hooked me up with a local company and I got an internship, and ended up doing simulation and chemical research that universities love. Went back to college and networked with some professors and research groups there and got on a Department of Energy grant. Built skills / reputation and then went off solo consulting.
All this is to say while I enjoyed "the process" of messing around with computers, figuring things out, and going to engineering school, I don't enjoy it anymore. I hate the office life and looking at a screen all day, and politics and meetings. It's just not for me. I found out I really like turning wrenches and seeing physical things being built. I like "blue collar" work more.
I think I put up with it for as long as I did because I was chasing money. I wanted to save money, but it was also a measuring stick for "let's see how much I can charge and justify my ability."
Yes, absolutely. This is way more fun than anything else I could imagine doing for money. Certainly not for this much money.
I only ever do contracts. Short ones preferably, so that I can have as much time off as I need to recharge. My current one is a part time, 2-3 day week gig with a startup that's building a popular product. It's mostly young kids, so they choose stupid but fun tech to build their thing on, which means there's always lots of fun cutting edge technology to play with. I treat it more as a hobby than a job, so I'm happy if they decide they don't need anything built for half a year
My main income comes from a couple feature complete SaaS products (that are also fun to work on) with enough paying customers to keep the bills paid, built on a sensible, boring, stack so that they don't need my day-to-day attention so that I can spend my days on more important things like bouldering, travel, and family stuff.
But yeah, I couldn't imagine being in this position with any other sort of profession.
Conversely I have learned to distrust any software developer's opinion on a subject of how easy it is to do something, especially when it comes to replicating the actions by a layperson, when they blurt out "Oh, it's easy, you just..."
"Oh, it'll be easy to distribute this update to our customers (who are Doctors), you just have FTP into our server, unzip it, and copy the files into your Program Files directory."
"Oh, that's an easy problem to solve, you just have to get the client site to standup a docker container on their infrastructure and..."
Agree 100%, it has blown me away my whole life how engineers downplay marketing and [product|personal] presentation in spite of the reams of data suggesting it has some of the best ROI possible of anything you can spend your time improving.
Do you want to make more money, get more connections, have everyone like you more and treat you better? It's as simple as buying some nicer shirts, getting regular haircuts, and eating better (which has its own host of plusses).
Some programmers are 55 and really good. They also have stains on their t-shirts, are overweight, and act morose all the time. In a perfect world this wouldn't matter for a job interview, but you are not interviewing or operating for a job in a perfect world.
Two things on how to get a better deal, which is how I have bought my cars since forever.
First, bank line of credit, or credit union loan to cover the cost of the vehicle. Usually far better rates, no early payoff penalties, they cannot repossess the vehicle if you stop payments because the loan/credit line isn't secured against the vehicle. And a line of credit can also be used for other purposes.
Second, Hertz fleet sales. Two or three years old. Top notch quality. Aim for the higher end or boring vehicles (higher end Audio & BMW, Lexus, Toyota Avalon, Range Rover) and they will have low mileage. Kia and the budget cars always have high mileage even on the newer vehicles.
In forty years we have only ever bought one "new" vehicle, and that was the off-lease company car that my wife had through her job - so we owned the vehicle for five years, then bought it for a song.
We purchased 2018 Toyota Avalon with all the optional extras at the tail end of 2019, under 20K miles, for about $18K. We just paid it off last month. Our credit union was happy to give us the loan and very happy for us to pay it off early, and there was no early payoff penalty.
There once was a language that compiled in milliseconds - you pressed a single button and your changes were instantly in front of you. What's more a clever separation of data and code meant that this instant reload would show your newly compiled app with your data still in place, and you looking at the same screen as before, exactly where you had left it, except powered by your new code.
This separation between data and code also enabled trivial scaling for huge system, as well as the opposite - hundreds of apps, each belonging to a different customer could share the same system - decades before docker or k8 was born.
This language was written when Objects were the only thing people talked about. In a counter-cultural move, the language's author wrote the entire standard library as only functions. The language could be easily learned - just look at the list of functions for the one that does what you want.
It's cross platform - the user interfaces you build work on all platforms with a single codebase.
Its combination of scaling, quick development iterations, and ease of use powered the rise of fourth largest tech company in the world today. In fact, just a single app written in this language has more than a billion people using it every day.
Darkly, however, the name of this language may not be spoken here. Even by praising it obliquely, I risk censure, and my perceived value of my work being cut by eighty percent in penalty.
I'm on Feeld and wow the headline for article is a weird take.
Compared to Tinder and Bumble there aren't many people (which isn't surprising) and it's very explicitly about non-vanilla sex, and I would never have thought that "emotionally mature" would characterize the people on it.
I'm in my 40s and I have trouble finding people my age. It's ok if you want to find a rope bunny or something like that though.
When I was in a relationship we tried it for threesomes and TBH had more luck with that on Tinder.
Also the "cores" concept is just strange. Why did they choose the cities they did? In Australia you can see who is in Melbourne but not Sydney (And Sydney is kind of an iconic gay city, which has a lot of cross over into kink).
Absolutely lol, I joke with my girlfriend that 50 shades of gray was the best thing to ever happen for my sex life. I had a Tinder profile with some kink stuff in my bio, my collection of gear/toys and (with her permission) a technically SFW picture from a previous encounter of a girl tied up and suspended. Went from a few matches a week to getting literally dozens a day as soon as I added that stuff to my profile, my current girlfriend being one of them actually.
In such situations I tend to ask that question directly:
"It was my understanding that you looking for someone who will help you with Django tooling. I can do that. Although number theory sounds interesting, I never felt the need of diving into it in order to solve any Django-related issue. I would be happy to learn more about how you think number theory relates to Django tooling should I start working here."
When people try to be important like that, it is paramount to take them at face value. In a lot of geek environments this happens all the time. People trying to push that one niche topic they really know about, because this is their comfort zone. The problem is: that one niche topic will rarely be a natural fit for any given conversation. More often than not just asking how they think this relates to the conversation at hand is enough to tame them a little bit.
Many times the stuff people say will contradict with the stated (or implicit) goals of a conversation. in this case the chosen topic was one with which the interviewer felt at home.
So another approach would have been to make it even more about them by e.g. instead of answering their question showing that you did your research: "Ah number theory! I saw you majored in number theory, I admittedly never had the need to dive too much into it — what role does number theory play in $Companyname?"
> Guidance is expected; a great interview should be more of a conversation than a one-sided question and one-sided answer.
I had a particularly awful interview at Google where the interviewer scoffed at me needing assistance.
And in an interview at Twitter with a xoogler they asked me what I knew about number theory and I said "nothing" and they said they majored in it and proceeded to ask me number theory questions. For a Django tooling position. He asked me how many prime numbers there were and I said "optimus prime" and he looked at me and asked if I was serious and if he should record my answer. I said yes followed by "autobots roll out"
I'll answer the questions you asked, then give you a better question:
AppAmaGooBookSoft are probably not what you're thinking of when you say "startups" and 5-10 years in any of them will make you quite wealthy indeed, by the standards of e.g. the American middle class.
Do some devs make north of $1 million a year? Yes, for a value of "some." (If you put a gun to my head, I'd say "Maybe 5% of the engineering workforce at AppAmaGooBookSoft. Possibly modestly higher than that in finance.") The shortest path to it is "significant contributions to a major revenue driver for a large company combined with aggressive negotiation."
Depending on where you draw the bar for "wealthy", there are a lot of dev-related businesses which can get you there. Consultancies with employees throw off a lot of money on a yearly basis and also build value which can be sold. Profits for a well-managed e.g. Rails consultancy are on the order of $2.5k~$10k per employee per month (math here: https://news.ycombinator.com/item?id=7155387), so if you run a 10-person consultancy, you do pretty well for yourself via distributions while also drawing the market salary you're paying all the employees.
There exist many product businesses which are primarily or largely software in character. There exist hundreds of software companies which toil in relative obscurity whose founders are (generally very quietly) millionaires even when one doesn't count the value of the company itself. I built a consulting career off of working for SaaS companies with, in the main, $10 to $50 million a year in revenue. There exist lots of them. The rough economics are often 10% COGS 10% marketing 10% G&A 50% salaries 20% "whatever the owner feels like."
Many of these paths will not involve you being primarily working on compilers and dev tools. (Compilers are a tough sell -- dev tools perhaps less so. There exist plenty of great small dev tools companies.) Even if that is what your business actually makes money on, you will probably have to a) get into business and b) spend the majority of your cycles on building the business rather than building the thing the business makes, unless you take the well-compensated employee route.
There are your answers. Here is my question: what do you want out of life? What does "wealthy" mean to you? What motivates your desire to retire early?
I once wanted to retire early, but that was a symptom of the underlying affliction "I hated what I was doing for a living." If you see wealth as an opportunity to choose to spend most of your cycles on something other than what you presently do for a living, you probably can achieve that without being sold-a-startup-now-I'm-loaded wealthy. Some of the happiest people I know run quiet little cottage industry software businesses on the Internet in preference to the day job. Most don't have seven figures in the bank, but their day-to-day lifestyle might resemble that of a "gentleman of means."
If you want to have sufficient free cycles to study something, consider as an option "Create some enduring source of value which solves the sustenance-for-myself-and-family problem with the minimum number of hours required per week; spend my freed-up-time studying rather than filing TPS reports."
Get an accountant as soon as you have $10k in revenue. Open a new CC account; put all business expenses on the CC. Keep a detailed travel log so that you'll be sustained on the possible eventual audit of your travel expenses.
The single best thing a consultancy can do to decrease tax burden is keep really good books on expenses. Don't drop $14k worth of CC receipts on the floor prior to entry; that costs you $5k+.
Also as a software engineer you get far, far, far more economic advantage from working on your business than from tax optimization. Get people to do that for you; spend as little time and brain sweat on it as possible.
I use bench.co for bookkeeping. Best money I every spent.
Talk to your accountant about retirement funding options; they're the modestly-more-brainsweat required option for decreasing present-year tax burden.
I have some stuff running with minimal maintenance, never any surprises, just chugging along year after year.
These services are practically stackless: there’s a Node app with Express as the only dependency. No database, persistence to local files, entire data model cached in memory as JavaScript objects. When the service restarts, it rebuilds the memory image from the file system. The data formats are a mix of mostly append-only logs (JSON lines) and some plain JSON for objects where it doesn’t make sense to keep the full change history. Backups and restore to another server are super easy when there’s a bunch of files and a single Node script to launch.
Lately I’ve been building a hobby product where the front-end is stackless too. Plain HTML and modern JavaScript, using ES modules in the browser. No build chain at all. I don’t need to support IE so all modern language features are natively available, and the app is small enough that a bundler doesn’t deliver huge benefits. This means I don’t have access to npm, but so far it’s been fine because browsers do so much these days and the APIs have improved tremendously in the past decade.
I’ll probably stick with stackless for anything I maintain alone and doesn’t have huge growth expectations. But I wouldn’t expect to convince anyone else in a professional environment, so in the real world there’s no escaping from half-gig node_modules and complex Docker builds and all that dance.
Every job I’ve ever had has been because of hackathons. Either being directly approached by a sponsor at a hackathon, or being remembered by someone involved with the hackathon after the fact. I briefly did a stint in a wildlife conservation NGO and even that came about because I had helped out at a hackathon at a zoo once.
I don’t think hackathons are particularly unique, I’d abstract this to “be visible and known in your tech community”.
I was always kind of confused about how advice for interviewers always comes along with warnings of the type "Some people talk a good game about programming, but they can't actually do it. You have to watch out for these people. Never hire one. This is the biggest trap you can stumble into as an interviewer."
After getting some interview coaching, I think I understand how this complaint arose. The whole problem is an artifact of the interview format, in which the design intent is for the candidate to be unable to solve the problem on their own. So you get scored based on how well you can charm the answer out of your interviewer while making them feel like everything they said was your idea. Instead of a test of how well you can program or solve math problems, it's a test of how good you are at cold reading. ( https://en.wikipedia.org/wiki/Cold_reading )
And unsurprisingly, a test of cold reading will end up delivering people who are good at cold reading without reference to whether they're good at other things. If you want to avoid this problem, just start giving assessments that don't involve interaction with the interviewer.
About half of the 30 or so bands I have played with have been abandoned after a couple of gigs, or non at all.
Mostly I've only just played music for fun. It's much more fun (and certainly easier) playing at some friend's house every week for 18 months than it is to book performances, market the band, produce works for the public, etc.
I have a sticker on my truck that says "This Sticker Will Last Longer Than Your Band", and that's been true.
I don't regret learning to play the entirety of Dark Side of the Moon and performing it once. I know so much Grateful Dead. I've play dozens and dozens of original songs written by friends that won't ever get any attention outside of the 20 people who were paying attention at some bar.
I've also played with more commercially focused endeavors and have an idea of the horrors of trying to tour and manage the commercial aspects of music. It's not like most of these bands were any worse or could not have been marketed.
I've played with a lot of folks who have only ever been in one or two bands.
The thing I find interesting about all that is this point:
they usually vastly underestimate how much work it takes to market a band
and at the same time (I find this a little beautiful) they vastly underestimate the goodness of their own musical output.
Just because projects don't succeed commercially does not mean they aren't well made or that these projects are not worth doing in as things in themselves.
Exercise. Don't drink. Eat well. Skip news/media that adds nothing. Read vociferously. Get plenty of rest time. Appreciate the downtime because it's not downtime it's valuable reflection time. Doing several slow things at the same time works.
Examples: Walk to the subway, bus. Don't be in a hurry. When getting to the stop, take 3 or 4 minutes to chill and appreciate the sky, plants, whatever you have.
Wake up earlier so as not to be in a hurry. Eat satiably. Cook if you like. Cook a little more and take a packed lunch. Cook for loved ones. Take the stairs not the escalator. Read a book on the subway about something completely different than your 'jobs'. Listen to a quality podcast while doing morning stretching or abs.
Wish others a nice day. Being positive breeds positivity. Plan ahead minimising catch-up. Engage in office banter, do more. Always be the owner. Synergies happen in the funniest of places. Never feel guilty for reading around or into a subject more than's needed. Don't feel guilty for not knowing something. Give time generously. Take lots of breaks. Laugh vigorously when realising something was so simple. Take another break. Do not work a job that measures you on time. Drink plenty of water. Never forget what's most important for you.
“I tend to think the drawbacks of dynamic linking outweigh the advantages for many (most?) applications.” – John Carmack
<rant>
I don't like to be a parrot for the Plan9 people [1] (they've been winning their own fights for a while now), but they've assembled a better set of citations than I could in the time I'm willing to devote to an HN comment.
Dynamic linking is fine, in very specific, very limited cases. Python extensions. Maybe you want to do a carve-out for like, some small hardened core of an SSL implementation or a browser because you've got actual hot-deploy in your (massive) installation/infrastructure.
As a basically mandatory default it's a chemical fire next to an elementary school. It started gaining serious traction as a horrific hack to get a not-remotely-finished X Windows to run on Sun boxes in like, +/- 1990. It wasn't long before the FSF had figured out that they could bio-weaponize it against interoperability. The `glibc` docs are laughing in their beer while they explain why static linking on "GNU" systems is impossible, and also makes you a criminal. They don't even pretend to make a cogent argument (they said the quiet part loud on the mailing lists). It's to kill other `libc` and `libc++` (fuck you small-but-vocal anti-interoperability FSF people!). Don't want LLVM to finish you off? Start interoperating better. There are a lot of us who think "Free Software" has to mean that I can use it in legal ways that you philosophically disagree with, and if it happens to be better than your Win32-style lock-in? Well that's just groovy.
Dynamic linking by (mandatory) default: Just Say No.
Myths:
- People want it: Docker. QED.
- Secure: Dynamic linking is the source of tons of security vulnerabilities. More generally, the best way to not trust your system is to not be able to audit the literal code you're running without jumping through insane, sometimes practically impossible hoops. If you want "father knows best" security, you need self-patch like Chromium and shit do now. And if you're willing to trade performance for security by the gross, flat pack or something.
- Performant: Dynamic linking forces address patch-ups, indirect calls, and defeats many optimizations. It thrashes TLB. It slows startup of even simple programs.
- Necessary: Text pages are shared. I don't care if you've got 9, 90, or 90k processes using `printf`: it's going to be in the same text page unless something else went badly, badly wrong.
I am assuming you know the answer to the question if you have been developing code for awhile. What makes the problem worse is that it is transitive. I link against Colmap libs, which links against Ceres libs, which links against OpenMP, … these are ever changing code bases and I have to create executables that run on local machines, Azure cloud machines, AWS cloud machines, … chafed down shared lib mismatches becomes a nightmare.
I’m pretty sure the reason is “X11 was large and badly factored, and people who should have known better thought it would save disk space.”
The problems they claim to solve are updates across applications at once, but in the enterprise how often does that actually happen? Application authors still have to test against the new version, and sysadmins still have to roll out the changes required to support the update. In practice they may as well statically link.
Let’s not forget the problems they introduce are significant. Implementations are complex. Applications become less portable. ABI versioning is a pain (versioned symbols are gross). Semantic changes in the shared lib cause chaos. Exec is slower because of the linking done at load time. Dynamic libs are bigger than static ones, AND they’re loaded into memory. More difficult to verify the correctness of a given executable.
The alleged “benefit” here really does not outweigh the cost. If we were doing static linking from the beginning, it’s difficult to say if we would have wound up with things like docker or nix in the first place.
Oh, yes, I certainly would. Shared libraries are an expensive, trouble-prone solution for that relatively uncommon problem.
Anyway that's not why we have shared libraries. They were invented so that memory managers could load the same library once, then map it into the address space for every process which used it. This kind of savings mattered back when RAM was expensive and executable code represented a meaningful share of the total memory a program might use. Of course that was a very long time ago now.
I met my current boss in school. We did a project together. I later learned he was a VP of a midsize company. I asked if he needed an intern to build some stuff, he agreed.
I have been building stuff for them for 5 years now as a full stack individual contributor. I am well compensated. I work whenever I want, some times more some times less. I definitely have to focus on keeping my skills sharp, and go out of my way to learn new things.
I have plenty of other offers but none compelling enough for me to leave this setup.
How can you get in a position like this? Network. You need to meet people who hold high positions, show them what you can do and build trust.
You could also look at things that may affect YOU. A lot of non-tech things could use a dev. You could develop something and offer it cheaply to first few individual/companies and test it out.
