If you're interested in this, there's a good chance you would enjoy the TidalCycles language for generating music. It's been a mind-expanding experience for me, particularly w/r/t polyrhythms.
Achim from AirGradient here. Nice to see my blog post getting some attention.
I think the underlying picture here really is that I and my co-founder are both heavily affected by air pollution in Northern Thailand and are seeing how it affects the health of thousands of people.
We believe strongly that air quality monitoring should be affordable so that people from poorer regions and countries can afford air quality monitoring and thus protect their health by knowing when the air quality turns bad. This is one of the reasons why we open-sourced our air quality designs [1] and are working with many NGOs and Universities to bring accurate low-cost air quality monitoring to underserved communities around the world.
Since we are a self-funded company we do not have pressure to maximize profit but can work under the mantra "Impact first (and profit will follow if we do a good job)."
By the way, if you work in air quality research, we are currently running a global co-location test program and are interested in additional partners [2].
After nearly 4 years working on generating fake news, operating an army of fake accounts with a few dozen of more "real" like accounts, running an online newspaper that is the fifth most visited online newspaper in it's country (and I don't even speak it's language), let me tell you something that is the only thing you need to know when you are browsing the web - don't believe anything you are reading online.
I can't stress this enough. Know your audience and tailor your documentation to them.
You should write three types of documentation. One for users, one for admins and one about architecture.
User docs are simple. How do I use it. What are the API calls, etc. Admin docs are about how to install/break-fix/troubleshoot issues that are beyond user interaction. Architecture is how the system is constructed, why certain tech was chosen, etc.
There's nothing that makes documentation more useless than when you're trying to do something like install the software but you have to dig thru piles of docs about why Postgres was chosen over MySQL. If your users or admins cant find the info they need quickly, they'll soon discard the documentation and user/system ops will go back to word of mouth knowledgeable.
I really think good companies focus on this and those who are successful really shine.
Design is how it works, not how it looks. This article seems to mainly be talking about the "polish" of a design. There are more important principles which don't have anything to do with polish, such as not putting the Cancel button next to the Ok button.
Like everything in software development, it comes with "it depends".
- getting peer review on iffy code = 100%
- waiting for a PR to be approved for 6 hours, by 2 parties when it's typo fixes and adding some comments = ...
As a senior dev with over 20 years, I value code reviews from even junior devs. Heck it might spark a conversation that might mean everyone learn something, or get a refresher. It's also simply put: 2 brains are better than 1, particularly with codebase fatigue.
And by the way, in dynamic languages: even more so. Dynamic languages save you time in the writing side of things, which you pay back in the testing. Make no mistake, you are the compiler.
So my philosophy is if you feel this might benefit from another set of eyes, seek reviews. If you feel you're going to waste someone's time, don't.
But mission critical code, e.g. handling payment information, user privacy impact of any kind, business logic, should go through code reviews, on top of QA and UAT.
Trust people, don't trust code. And if you can't trust your people, you need new people(!)
This is unfortunately modern culture, and most seem unconcerned how rude they are to strangers. Very foolish policy unless you already have over a Billion market cap, and can attract a steady stream of junior staff more willing to take flippant abuse.
Rule #23: Don't compete to be at the bottom, as you just might actually win.
This also means respecting the content medium, and knowing when to bail. =)
Nobody tells this to people who are beginners, and I really wish somebody had told this to me.
All of us who do creative work, we get into it because we have good taste. But it’s like there is this gap. For the first couple years that you’re making stuff, what you’re making isn’t so good. It’s not that great. It’s trying to be good, it has ambition to be good, but it’s not that good.
But your taste, the thing that got you into the game, is still killer. And your taste is good enough that you can tell that what you’re making is kind of a disappointment to you. A lot of people never get past that phase. They quit.
Everybody I know who does interesting, creative work they went through years where they had really good taste and they could tell that what they were making wasn’t as good as they wanted it to be. They knew it fell short. Everybody goes through that.
And if you are just starting out or if you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Do a huge volume of work. Put yourself on a deadline so that every week or every month you know you’re going to finish one story. It is only by going through a volume of work that you’re going to catch up and close that gap. And the work you’re making will be as good as your ambitions.
I took longer to figure out how to do this than anyone I’ve ever met. It takes awhile. It’s gonna take you a while. It’s normal to take a while. You just have to fight your way through that.
My 14 year old son was frustrated with "Fun" math games as they were not really fun. So he started building his own games in p5.js and recently he launched these games at https://thegamebox.ca/
He has been making these games since he was 10yo, so there is a progression in quality. Last game he made is not a math game but a puzzle game (Red Remover) he used to play and love when he was very young and was no longer available.
He has done all the graphics as well for these games.
1) Make two lists. Write everything down in the first list. The second list is empty.
2) Something came up! One item on this list cannot be done. It doesn't matter why: you know which one that is. Which one is it? Write that down in the second list and mark it off the first list.
3) Repeat until the first list is done.
Congratulations, your second list is prioritized (albeit likely in reverse order), without extraneous algebraic diversions.
Bonus points for going Warren Buffett on it: only the top 3 priorities matter, sideline everything else; consider repeating the exercise after those three are complete.
I've read a lot of resumes in my time, and here is my advice:
No one reads resumes. At best they skim them. They look at the shortest lines, which are usually where you worked and the job title. Name recognition makes a difference here, no matter how many people tell you otherwise. This applies to your college as well. But don't let it discourage you, it's more of a "if you have a big name there you get a boost but it's not a negative if you don't".
They skim for key technologies and then read the text around them.
They most likely will read the full text of the most recent job, so make sure that is the most detailed and interesting.
Your resume should talk about results. Don't say "Created a new CMS for the company". Say "Created a new CMS for the company in Python that resulted in an ~70% reduction in website update times, from 1 hour to 18 minutes."
If you do put a "skills cloud" on it, be ready to talk about them all. If someone had a skills cloud I would immediately look for the most esoteric skills and dive deep on it in the interview (after Googling it myself) to see if you were BSing or not. If you really know that skill, you should know more than what I learned in five minutes of searching.
All this applies to your LinkedIn as well, which you should keep up to date, so that if there is a job you want but don't want to spend the time applying, you can just send them your LinkedIn. :)
Edit: Forgot to mention, as pointed out below, that your resume also drives the interview, so while some of what you write won't be read to get the interview, you still want it there as a place to jump off during an interview. Always better if you can drive the conversation towards your most positive qualities, which is easier if they are in your resume and the interviewer asks about them.
Many more mathematical scientists I know do exactly the same thing on occasion Mostly, in order to make progress you need to work at it a lot. Sometimes, however, you need to go away and let it churn away in the back of your mind before trying again and revisiting it with fresh eyes and new knowledge but with your old familiarity. One of the most useful pieces of advice I have ever received was 'try to procrastinate from work with work'. There's something about knowing that the solution to the problem exists (but you don't have it) that really motivates detailed study but will slowly drive you mad if you're not careful.
Rich people aren't necessarily happier, they just have different problems. I would try to be optimistic and think about all the problems you do not have.
Patrick Boyle breaks down the situation with his usual eloquence and dry humor. Video is worth watching just for the chart of the corporate structure.
https://youtu.be/zTFhnpf-IE0
I spent 7 years trying to get a green card in the USA. As a CANADIAN engineer. After two (non-FAANG) companies flubbed the paperwork, I gave up and moved to Asia.
Best thing that ever happened to me.
That “USA experience” I got working on large scale (millions of users a month) projects REALLY pushed me to the top of the market skills wise, even though I’d consider myself an OK web developer compared to my peers in California.
Now I’m living in Taipei, spending half of what I was spending in LA for double the life style. Got a remote contract that pays more than my previous job, and a nice tax break on top of that. I’m on track to get my Taiwanese PR next year (only takes three years).
So for anyone worrying about immigration after a layoff in the USA who has a few years xp already: you’re going to be fine. Its stressful, it’s scary, but the xp you have will still pay off in other markets. Especially with remote work.
Funny enough I did a similar thing for my country (Austria). Found quite a few strange things and even made a collage of screenshots of all webservers hosted in Austria - https://blog.haschek.at/2019/i-scanned-austria.html
I've used RSS to follow all media for the past 2 years (FreshRSS+FeedMe, I have a guide here https://soapstone.mradford.com/hn-rss-guide/). It's been the single best thing I've done to reclaim my attention. Here's a couple of other random thoughts:
- Being able to dismiss articles where the headline is the story is really valuable. For example, I just dismissed "Twitter’s mass layoffs have begun (techcrunch.com)"- it's not worth my attention.
- It's possible to accrue a large backlog of unread "semi-interesting" items that may or may not be valuable. In this sense, there's still a FOMO aspect to RSS, and you have to be aggressive in dismissing articles. For exmaple, a few 2-week-old backlog titles in my feed include "SHA-3 Buffer Overflow", "Show HN: Restfox - Open source lightweight alternative to Postman", and "Five origami books by Shuzo Fujimoto are now public domain". These are semi-interesting, but really I should just dismiss them.
I make heavy use of https://kill-the-newsletter.com/ to convert e-mail newsletters into RSS feeds -- IMO the RSS reader context is way better than an email inbox for consuming newslettery content.
I've done some messing around with GPT-3 also - you can see me trying to teach it what "funny" is. I convince it that it's sentient, and help it to figure out what phone phreaking is, and we write a couple stories:
Jobs imagines his garbage regularly not being emptied in his office, and when he asks the janitor why, he gets an excuse: The locks have been changed, and the janitor doesn’t have a key. This is an acceptable excuse coming from someone who empties trash bins for a living. The janitor gets to explain why something went wrong. Senior people do not. “When you’re the janitor,” Jobs has repeatedly told incoming VPs, “reasons matter.” He continues: “Somewhere between the janitor and the CEO, reasons stop mattering.” That “Rubicon,” he has said, “is crossed when you become a VP.
Depending on what you deem to be a suitable replacement i'd recommend:
nvim-telescope/telescope.nvim // integrates well with code actions and searching (very extensible in general, similar to ctrl-p)
hrsh7th/nvim-cmp
hrsh7th/cmp-nvim-lsp // for language server completion
neovim/nvim-lspconfig // a bunch of language server specific stuff
note, that you'll probably need a bit of time to configure it to your liking and that nvim doesn't install the language server by itself, so that is something that you need to take care of by yourself as well.
If you want to see what a preconfigured IDE-replacement might look like you can take a look at lunarvim(but beware, it misbehaves on windows quite a bit, you're better of with a linux system here)
I first built a simple thing.
But it was buggy. I learned about debugging.
Then I wanted to add features to it. But the code was ugly. So I learned how to refactor.
Then I learned about modules to separate things out better.
Then I started breaking up bigger features into smaller features and planning my implementation - sometimes in a notebook. So, white boarding was now easy.
I'd then write the pseudo code as comments first. For obvious things, I'd delete the comments as I replaced them with actual code. For less obvious things, I'd leave the comment in-place.
I also became proficient enough that I could write code for whatever I was thinking without needing to constantly look up syntax. This made me fearless during pair programming.
I also found myself solving problems that more senior engineers talk about when they talk about battle wounds. This was awesome because, as soon as I talked about my (fairly simple, really) projects, it made the interviewers happy. I've received at least two jobs this way.
One big takeaway for me from doing this has been that simple code is far nicer to work with and return to than clever code. If your code is so simple that even a freshman in college can understand it, then thats a good thing!
I created the Neat CSS framework in the same spirit. It's so minimalist that there's no publishing system; you just grab the CSS file and write HTML. I use it for all kinds of sites, including the occasional blog.
That reminds me of a Pratchett quote, an exchange between a respected local witch and a visiting priest:
> "[...] And sin, young man, is when you treat people like things. Including yourself. That's what sin is."
> "It's a lot more complicated than that--"
> "No. It ain't. When people say things are a lot more complicated than that, they means they're getting worried that they won't like the truth. People as things, that's where it starts."
> "Oh, I'm sure there are worse crimes--"
> "But they starts with thinking about people as things..."
These things seem to come and go in cycles. In a few years Substack will probably end up just like Medium as they try to "cross the chasm" - Typical VC-funded company incentives. There is already a lot of low-quality spam on the platform.
You don't need $50-100M in funding and (soon) hundreds of employees to run a simple newsletter site. This only forces the company to over-engineer and push intrusive monetization to make meaningful investor returns. Just like Medium, Quora, etc. These were great simple products, until the pressure to justify their valuation and return money to investors ruined them.
The landing page: https://tidalcycles.org/
An example of some music made live with it: https://www.youtube.com/watch?v=mlUOWjC5fpY