"I love deadlines. I love the whooshing noise they make as they go by."
-Douglas Adams
"I love deadlines. I love the whooshing noise they make as they go by."
-Douglas Adams
If you want collective outcomes that are different than the sum of uncoordinated individual action, you have to design them. Don't talk about "we." Who specifically is doing what, and for what purpose, and why would they do that, when they could just not?
Answering those questions often shows you that the problem isn't what you thought—because the mental model of a "we" that does things is so harmful.
Or you end up with a plan to solve the problem, so win-win.
Presumably the CEO would believe that improving the quality of their company's products will lead to increased profits/revenue.
I suppose. I do actually useful projects at work. AoC reminds me of why I personally loved programming in the first place - solving small technical puzzles. I don't like trying to make every single moment of my life "productive".
Perhaps if you aimed at global leaderboards it would be different, but that's neither my league nor I see any fun in that - getting there requires serious effort and preparation in things that aren't directly related to solving intelectual puzzles.
I find no particular pleasure in using an everyday language like Python for it, because as you said it's too easy.
I have used Haskell, Racket, and in some easier cases APL and it's been fun. Treating it more like a puzzle than an actual programming assignment.
When learning new languages, it's best to do something that actually makes you think in a different shape. If you know Python, don't do Ruby. If you know Java, don't do C#.
function throwError(error) {
throw new Error(error);
}
async function createUser(user) {
validateUserInput(user) || throwError(err.userValidationFailed);
isPasswordValid(user.password) || throwError(err.invalidPassword);
!(await userService.getUserByEmail(user.email)) || throwError(err.userExists);
What if... [
[() => validateUserInput(user), err.userValidationFailed],
[() => isPasswordValid(user.password), err.invalidPassword],
[() => !(await userService.getUserByEmail(user.email)), err.userExists],
].forEach(function([is_good, error]) {
if (!is_good()) {
throw new Error(error);
}
});
Also on the regex: const rules = [/[a-z]{1,}/, /[A-Z]{1,}/, /[0-9]{1,}/, /\W{1,}/];
No one caught that in all four of these, "{1,}" could be replaced with the much more common "+". A bit odd considering the desire for brevity. I do personally prefer "[0-9]" over "\d", especially considering the other rules, but can go either way on "\W".I might have also added a fifth regex for length though, instead of doing it differently, if my head was in that mode: /.{8,}/
You're doing so much extra work here. Creating many new arrays, running a bunch of extra function calls, creating extra closures, and really obfuscating code from the engine. This will tank performance.
This is the point at which people come back at me with something about "premature optimization" being bad. That's all well and good, but if you prematurely pessimize and let these patterns creep throughout your codebase, you end up with products that are significantly slower than they should be.
I've spent quite a while working on JS engines, and it always impresses me how much extra work exists in JS developers' code, seemingly for no real reason, and it's slowing down the entire internet. This doesn't appear to be better for the developer, the user, or any potential future maintainers.
The Kobo can run in a fully offline mode (called "side-load mode" or something like that) and I can transfer my ebooks directly via USB. I use the Kobo most of the time now since most of my reading lately has been independently published ebooks, but I still use the Kindle for books I purchase via Amazon directly.
With all that said, I personally think the Kindle Paperwhite is already the perfect size. It fits snuggly in my back pocket and strikes the perfect balance between screen size being large, but not too large to hold for my average male hands. I'd be a bit concerned about the size increase for my personal use case, but Amazon does a great job with the Kindle in general so I'd like to see some reviews.
As for the new Colorsoft, I'd really like to see some reviews. The color Kobos that came out earlier this year got some mixed reviews for colors, but I'm not sure if that's just the nature of color e-ink or not.
Interestingly, I switched from Kindle to Kobo because it was lacking various basic features that made it not feel premium.
* Kobo epubs can show "pages in chapter" progress so I know how much longer there is until a nice stopping point, while Kindle only shows "minutes left in chapter" which is functionally useless.
* Kobo had blue light blocking night shift before Kindle Paperwhite (I think both have it now?)
* Kobo had a convenient feature where you slide your finger along the side of the screen to change brightness, instead of having to go into multiple menus to do this.
It's possible these things have been remedied, but especially the chapter progress thing put such a bad taste in my mouth that I never wanted to touch Kindle again.
I know that that critique isn't new to anyone but it makes me think about how it would be cool if there were a code puzzler site that is specifically geared towards little self-contained tasks that are more to do with forcing you to get familiar with the common everyday tasks of software development.
Some example puzzlers could be like:
- open an http server on port 80
- open a file and write this data to it
- write temporary files to a location, deleting them when process exits
- query a database
- deal with such and such error scenario
- find a way to test this component
- bundle this code as an executable
- sanitize user input here
- make this behavior configurable
- take the config from environment variable variable and/or config file and/or arguments
- parse this data file
You do get a bit of parsing and file handling with Advent of Code but imagine a series of dozens of small problems that grill you on every corner of the python filesystem api. Would be a lot less dry than reading docs cover to cover.
I've done a fair amount of Advent of Code and I wouldn't say it's at all "focused" on this. The vast majority of the questions use hash tables and graph traversal as the full extent of their use of math/DS/algos.
There's always one or two puzzles every year that require some particular math/CS insight but most of them just need you to know BFS and/or how to write a parser.
Your examples are also not bad, but they seem to be primarily concerned with "getting familiar with a new programming language" in the context of writing a web server, which is one of the parts of programming I try to stay away from. Most of your examples require less familiarity with the language's features and more with libraries you might use, which is less interesting to me personally (then again, I'm a PL fan and I write compilers for a living).
Meanwhile, I like AoC because I've used language features to take the fairly straightforward potential implementations and write them more elegantly in the language I choose. e.g. I use Monads in Haskell, or use Rust's easy threading to parallelize solutions, etc.
For me, learning a new programming language is largely uninteresting unless it changes the fundamental "shape" I think in, rather than what the exact names of the libraries I use change to. e.g. I already know Java so I'm not really going to bother "learning" C#. I already know Python so I don't really bother diving deep into Ruby, etc. However, I learn Haskell, Rust, Forth, Erlang, Scheme, etc.
C-level - sets highest level strategy (We're going to the moon!)
VP - adds level of detail to strategy (draws a map from earth to the moon, decides we need a rocket ship to get there)
Director - bridges strategy and tactics (creates high level requirements the rocket ship, makes sure there are enough gas stations on the way to the moon)
Manager - ensures tactical success (ensures the team builds a rocket that meets the spec, makes sure the rocket stops for gas on the way)
And of course, for a sufficiently large org, some of this gets offloaded to dedicated Product Managers, Program Managers, etc. But, that's orthogonal to the point of the article, I think.
VP - Tells directors to work faster
Director - Tells managers to work faster
Manager - unblocks team
ICs - do real work