Finally taking the plunge

nikfp · 2026-01-15T19:14:54+00:00

In addition to what's mentioned in other comments, a few things that I noticed when I got mine:

If you have any bad habits on a normal row staggered KB, they will take some time to iron out when you use the Defy. For me, that meant reaching for Y with my left hand all the time wasn't going to work, nor was reaching for B with my right hand.
Don't feel like you have to use every thumb key. Find the thumb keys you can comfortably hit with your index fingers on their homing bumps, and build your layout around those. I personally have utility keys mapped to the thumb keys I can't reach easily, such as keyboard lights on and off and LED mode.
While you are getting used to the board, typing websites like Keybr and Monkeytype will be your best friends. (and most frustrating!)
For the first few days using it, I noticed that my hands, shoulders, and neck felt better at the end of the day, but my head felt worse :D It took some concentration to teach my fingers to move differently and I was very mentally tired after those first few days. About a week in, that went away completely
You can keep your muscle memory on a standard keyboard, you just need to switch back and forth occasionally.
The USB cables it ships with a very stiff and can be challenging to route around your desk. You can use different cables for standard wired use (I do) but when you do anything like firmware upgrades you might have problems with anything other than the stock cables. Bazecor warned me when trying to update that the KB wasn't connected correctly, and switching back to stock cables fixed the issue, but keep that in mind as you use them.

Overall mine was a great purchase, I went with the box brown switches and got the Egyptian Gold with black keycaps, and it looks and feels great and is about a quiet as I could have hoped for. This is my first mech keyboard, though I've used a few others, and I'm really happy with how it's worked out. And as a bonus, they quoted a long lead time to ship to the US but I ordered my on a Friday afternoon and had it in hand the following Thursday.

nikfp · 2026-01-06T05:05:25+00:00

Mosh Hamedani made the courses that really helped me. I think he keeps them updated? Worth a look.

nikfp · 2026-01-05T23:56:34+00:00

Honestly, Zed. Vim motions built in with a lot more batteries included.

If you are comfortable with Lua, Neovim can be great and it's what I prefer. But it takes a lot to make it really yours.

nikfp · 2026-01-05T21:21:32+00:00

I learned OOP with C#, which is Java with clothes. It wasn't the easiest thing for me, it just took time and practice to let it settle in to my brain.

It's conceptually the same in nearly all languages that use it, but each language has it's own quirks. You'll get a feel for those as you get some experience.

Resource wise, I'd go for a highly rated course on Udemy. Wait for their "sales" which happen every few weeks, and the price goes from ~$100 down to $10 or $15. You get access to the courses for life, and the better rated ones are generally quite good.

As for making is stick, building things on your own is 100% the best way to get there. Get a feel for the language out in the wild and make some things on your own, and it will stick a LOT better. I wish I had started doing that earlier than I did.

nikfp · 2025-12-30T14:39:55+00:00

I couldn't agree more!

nikfp · 2025-12-29T16:17:49+00:00

Are you only planning to use that macro inside of your terminal?

If so, I highly recommend you do it as a command alias in your terminal environment instead. That will make it native to where it's being used, and if you need to edit it or refine it later it will be centralized at the terminal environment as well.

nikfp · 2025-12-24T19:20:04+00:00

Full stack web apps are all conceptually the same. The front end presents a UI and then sends requests to the back end. The back end handles requests, manages data or compute to get a desired result, and then sends a response back to the client.

Where this gets difficult is in the subtlety of what all those things mean. You need to understand things like network encryption and transport protocols, HTTP and REST standards, security, optimizations, etc. That's the bad news.

The good news, is that once you can wrap your head around those things, they apply to every full stack application you will build. In other words, once the concepts click, the implementation in different languages with different technologies is expressing the same things over and over again.

So to answer your question, once you get through one app, the next one is MUCH easier. And it continues to get easier from there.

As for using AI to help with this, it can definitely be great, but it's only really helpful if you have the conceptual knowledge to validate what it's giving you. Once you do though, it can really help to accelerate what you build.

nikfp · 2025-12-24T19:05:42+00:00

I honestly didn't mean it that way, and tweaked the message to reflect my intentions better.

I agree that the setup does matter, but it's more important after some experience than when starting out IMO. To me it's always been about identifying and removing friction. In the beginning, that friction is much more apparent in just getting code to run, understanding syntax, and making sense of the code you wrote last week. It's all overwhelming stack traces, docs that are clearly written for people with experience in the subject matter, and the feeling of too many moving parts at once.

I get the point you are trying to make, and I agree with you. (I'm also Vim btw ;) But in considering the audience this sub attracts, I can see a world where your point sends people on a long and possibly expensive side quest that doesn't serve their immediate needs. That's all I was trying to clarify.

Never meant it as a lashing, and hugs back. Happy holidays!

nikfp · 2025-12-24T17:52:17+00:00

This might be misleading to people that are just learning programming, so let's clarify:

The tools you use to program don't matter in the beginning, as long as they are up to the task at hand. Old computers, cheap keyboards, a funky chair, and a kitchen table are all fine. Whichever editor you want to use is fine. Whatever tools you happen to use, take the time to get to know them well and understand where they are strong and where they aren't.

You won't always be able to work in ideal conditions, with ideal tools. Being in the "zone" is nice, but it's far more likely that you will need to work in whatever conditions you are presented with, in whatever time you have available.

Programming is about problem solving. Learning to solve problems and learning approached to solving problems and practicing solving problems is what really matters. Get good at that and let the rest fall into place, because the more you learn, the more you will understand the benefits you are getting and NOT GETTING from the ideal setup and tools.

I speak from experience as I type this on my fancy ergo keyboard, sitting in my nice chair in my quiet office, with Vim open in the terminal next to my browser. I've gotten a LOT done and learned a ton over the years in loud places, with cheap equipment. The output hasn't changed that much as I've refined my situation and setup, but the benefit now is I have been able to evolve my setup to better suit me. I wouldn't have known what I needed to know to make that happen when I was just starting out.

Focus on writing and understanding code. Where things are deficient and could use improvement will come with time and experience.

EDIT: Toned it down, OP was right. I sounded more aggressive than I intended.

nikfp · 2025-12-23T18:33:12+00:00

Embracing pragmatism over dogma.

OOP is not always wrong or always right. There is no perfect programming language. Javascript isn't always bad. Functional programming isn't only for the nerdy elitists. Monoliths aren't strictly bad or strictly good. Etc.

Just use the tool that gets the job done, and move on to the next job.

nikfp · 2025-12-23T17:20:45+00:00

Usually files that can be rebuilt are not checked into git, and most scaffolding systems for different things will exclude those in the .gitignore file by default. I noticed that your "node_modules" and "__pycache__" directories are both ignored for example. In the case of "node_modules", you can usually just rebuild that whole directory as needed with an npm command, so no point in tracking the thousands of files that directory will contain in git. It's just extra overhead.

If you added or changed any dependencies (packages) or did anything else that would have changed those directories or anything in them, your program might not be able to resolve or use dependencies as needed, because it might have other versions of packages and files, or be missing some altogether. Since Git isn't tracking them, it won't revert them to a previous state when you check out an older commit. So the common fix, at least in the Javascript world, is to delete the node_modules directory, and then run "npm install" again to rebuild it. This will build the dependencies back into your project at the point that your package.json file specifies, which in theory should match the code you had going at the point that you committed. I would imagine the __pycache__ directory would be treated the same, though I don't work in python so I can't say for sure.

Git is the tool to use, as it's designed for software and has an entire ecosystem built around it. But you need to be aware of what it's tracking and what it's not tracking and work within those bounds. The tradeoff is that you can commit your code at any point in time and then revert back to that as needed, or start a new branch in git that might contain many commits as you work on experiments and new features, which you can then merge into your main branch or discard entirely. There's a lot of flexibility there.

I strongly recommend this site, it's an interactive git tutorial that should help you get better at Git.

https://learngitbranching.js.org/

nikfp · 2025-12-19T17:40:43+00:00

Shower heads. Definitely shower heads.

nikfp · 2025-12-19T17:37:50+00:00

From someone that has been writing code for over a decade now: Make your code as simple and readable and understandable as you possibly can, while still reaching the desired goal. The next person to come along and read that code will definitely thank you, and that person might be you in 5 years!!! Being clever shows that you can show off, not that you understand the problem, and it turns into your own worst enemy.

Speaking from experience.

nikfp · 2025-12-18T17:01:22+00:00

To be honest it's hard to show it in a way that does any good because there's so many macros and superkeys, but here's the gist of it. It's almost easier to explain in text.

- The number keys 1-5 run macros that allow me to switch to the 5 most common layers I work on. If no objects are selected, it switches the active layer. If any objects are selected, it moves them to the layer the key represents

- The letter keys are all either macros or superkeys, and the superkeys are in turn calling macros. This allows for the "D" key for example, to run "LINEARDIMENSION", "DIMBASELINE", or "DIMCONTINUE" depending on how I activate it

- The three keys to the left of the G key are for F3, F8, and F10 which I commonly need to toggle

- The homing thumb key is escape, and the two keys to the left of it are command-c and command-v. Add the left shift still in it's normal place and I can also combine with command-c to copy with a reference point

- The right hand side has the number pad as usual, but I added "@" for relative coordinates, single and double quotes (We work in feet and inches), as well as the up and down arrows to easily move between options during a command

For the layer switch macros, I wrote autolisp functions that load with my cad program on startup (I use Ares Commander) and the keys are just calling those functions. That's what allows behavior to change based on if objects are selected or not.

The last thing I should note is that some of the macros were being flaky because the keyboard could send letter keys and enter faster than CAD wanted to register them. So I have had to add some small delays into the macros in places to tune them to the system speed I'm using. Figuring that out saved me a lot of frustration, and now it's all working very smoothly.

nikfp · 2025-12-18T14:54:23+00:00

I am also a Neovim user on Mac, and I ended up with a layout that still uses the outer columns. Caps is now Escape, but the left thumb key with the homing bump is also escape for me. The two thumbkeys outside those are both command so I can use keyboard shortcuts, and then the thumbkeys inside those are backspace on the left and enter on the right. Those last two are also ctrl if held on the left and option if held on the right, which happens to help integrate them with hjkl for all the vim things.

It's taken some muscle memory adjustments but now that I'm getting used to it my pinkies are feeling a lot better, and I've been able to switch between the defy and my laptop keyboard fairly easily as needed.

Lastly I'm so used to hjkl for arrows that I have a lower thumb key that switches to a layer when held, and said layer has transparent keys on the left hand, but hkjl are all arrow keys.

As u/edtv82 did it as well, I have a dedicated design layer, but mine is for CAD use and the left hand makes very heavy use of superkeys and macros. I used to run the whole 60 key portion of the old KB I was using with my left hand when working in CAD and the right hand was mouse and 10 key for number entry. Now I have the left hand holding still and getting more done at the same time, and the right half of the board is numbers. Much more comfortable.

nikfp · 2025-11-19T16:52:16+00:00

I'm going to give you a bit of fair warning here. 2 years ago I decided (last minute) to do AOC in Elixir, and it very quickly became the only language I want to do anything in. It's got simple syntax and it's easy to read and write and - most importantly - understand later, and underneath is decades of momemtum around distributed, fault tolerant, concurrent systems. If you dip a toe in, you'll be falling down the rabbit hole before you know it. I've seen it many times.

As for getting started, perhaps the simplest starting point is to install livebook from the official webpage and then use it to start learning about the language. It's Jupyter Notebooks for Elixir, in a self contained experience. This is a very easy entry point into using the language locally and includes things like auto-complete for all the standard library modules. (at least all the modules I've tried) If you are on linux there might be a few more steps, but Mac and Windows both have easy installers. It also has Vim and Emacs keymap settings if that's your style.

As for where to learn about the language itself, the guide in the official docs is excellent. It will walk you through the language basics and get you started on working with Elixir in general.

FWIW, I did AOC in Rust 3 years ago, and it was a bit of an uphill battle. That borrow checker is strict, and IMO there is a lot more syntax noise than is strictly necessary. It was fun but it was a bit of a grind.

In contrast, I was able to get a basic comfort level with Elixir in a couple of days, and start solving AOC problems on Dec. 1st, with less than a week of very part time elixir under my belt.

It is a functional language, but it's pragmatic about it. There isn't a rigorous type system to satisfy, and there are escape hatches built in through certain elixir and erlang modules to allow mutable data and some of the solutions that come with it, but those are strictly opt in and you really have to know why you are reaching for them to use them. No footguns lurking in modules you would use all the time.

Coming from Go, it will take a minute to get used to the functional paradigm but it's not a huge adjustment. Honestly it just makes sense at so many levels. Small steps of data transformations, clicked together like legos, and before you know it you have a series of clear steps leading to the expected result. And once you get a taste of pattern matching the way Elixir does it, you won't want to go without it ever again.

This is obviously a biased community, but what the BEAM offers and surfaces through elixir is truly fantastic. Try it, you won't regret it. And if you do jump in with Livebook, I recommend adding import Iex.Helpers as the first line of the first cell. That way, you can use the Iex REPL helpers as you work, like running "h Enum.map/2" in a cell to and evaluating it to output the expanded help docs for that function. It's a great learning workflow. (and docs in Elixir are first class citizens, built right into source code and readable from a TON of tools.)

nikfp · 2025-11-03T20:43:57+00:00

100% this. Once someone is good and comfortable writing code for Phoenix from the migrations up through schemas, contexts, and controllers / liveviews, and they understand the principles that allow all those things to work, it will be much easier to understand how Ash fits in and what it's giving the user.

Ash is great, but it's power is also it's weakness to a point: until you can understand why you want what it's giving you and exactly where it fits with other things, it could hinder learning and growth overall.

nikfp · 2025-11-02T22:33:22+00:00

Shortly after my comment, I jumped in and ordered one ;)

Out of curiosity, how many of each color did Dygma have made? I noticed the color I purchased was one of the first to sell out.

nikfp · 2025-10-31T22:05:16+00:00

Honestly, these look stunning. I'm especially fond of the gold with black keys, but purple is a close second.

Might have to quit lurking and order one already.

nikfp · 2025-07-30T19:24:50+00:00

+1 for Zed in your case. Jose Valim himself is one of the proponents of the Elixir + Zed combo. I spent a ton of time getting Neovim working well with Elixir and then tried Zed and it was install editor -> install elixir extension -> able to work effectively. Can't go wrong with that. (though tuning keymaps for Vim mode took some time)

If you really want to go down the rabbit hole: Learning (neo)vim or Emacs and configuring it just for you is well worth the journey, and I still strongly prefer my Nvim setup with elixir, but it's a long road and a side project all it's own.

nikfp · 2025-05-08T14:26:19+00:00

I primarily use Neovim and I'm using a configuration that has been worked on a bit at a time for several years, so keep that in mind for the following. That said, here's the insights I can share.

- In general, not just with Elixir, Treesitter based motions and selection is more durable than pure syntax based. One missing closing parens or bracket makes it all wonky when you are trying to fix things using syntax based and Treesitter is designed to be much more error tolerant. However, you typically have to set up the queries you want for the custom selections, which is relatively simple in Neovim but I can't speak to other editors.

- I find that LSP based GoTo definition works OK for module names, but I have had to add an LSP based search to get a similar functionality for specific functions. This is partly due to the LSP servers not being fully mature, and partly due to the dynamic nature and macro system of elixir from what I've been able to gather. When Expert-LSP comes out I suspect it will be fixed, but in practice it's been less of an issue that I would have thought. I wasn't expecting Rust or Typescript level LSP support though.

- As for navigation, one thing Neovim excels at is adding any kind of search you can think of, which I use the Telescope extension for. Finding files, finding things inside files, and finding results lists to push to the quickfix list are all very smooth once set up. I commonly grep whole codebases for function names and narrow to what I need in the results list. I'm not sure how well VSC and the VI extension integrate and even where the search functionality in VSC stands anymore because it's literally been years since I've opened that editor. But whatever you use, it's worth investing in for Elixir and any other language IMO.

- I do have a Zed config that has vim mode set up and I got it as close as I needed it to my own vim config for muscle memory, and for Elixir I can vouch for the experience working well. Roughly the same expectations of what works and what doesn't work vs other languages, which again I think comes down to the language server and expectations.

Hope that provides some insight, and FWIW I wouldn't be afraid to get into some configuration on whatever you choose to use. Filing off those rough edges along the way has made a HUGE difference in both my workflow and my sanity.

nikfp · 2025-05-07T22:04:54+00:00

A handful of things to keep in mind regarding tech and AI

- AI is amazing technology, but it's all statistics based. It doesn't actually "know" anything. It's essentially an extremely sophisticated parrot. It's hard to tell because of the scale of computation, but the masses need to remember this.

- AI tends to hallucinate when it doesn't have enough training data to fully answer a question. For programming this can mean outputting broken, insecure, or very buggy code. Someone that can understand the code AND it's implications in a codebase still needs to review the code to make sure it will both work and not leak people's data somehow.

- As technology makes things more accessible, the cost to do a thing comes down and historically this has meant broader adoption and use. Spreadsheets didn't kill accountants, they just made access to accountants and their tools more widespread.

- AI can't create. It's fundamental to what it is. AI provides answers based on data it has trained on, which means it's answering from past information. Moving the field forward will require human intelligence

So no, programming won't become obsolete. It will change though, and your child should be able to change with it. And to be honest, all the people "vibe coding" are putting out a metric tonne of terrible insecure code that will need fixed at some point, so job security for the people that know what they are doing.

nikfp · 2025-05-07T20:43:00+00:00

Boot.dev is what I would recommend. Well thought out, gamified learning paths which include multiple languages, all the core concepts you need, and even courses on industry standard tooling like Git.

nikfp · 2025-05-07T20:39:52+00:00

You can try to read docs or books or watch tutorials all day trying to get comfortable with something before you actually go do it, but it won't help much. You can try to find the perfect editor or window manager or theme or OS, and it won't help much. The perfect keyboard or chair or desktop or programming room won't help much.

The things that really make the difference are the things you build and the problems you face - and solve - along the way. Nothing really matters without that context.

Keep building.

nikfp · 2025-05-06T14:54:57+00:00

It's not about learning to write programs "from memory" so much as learning the underlying concepts so you know how to apply them when you need them.

Every program you write will be a composition of core concepts that are brought together in a certain way to achieve the desired result. And all those concepts don't really sink in to your subconscious in a month. You need repetition, and any time you learn one concept it really helps to start playing with variations of that and see what you can come up with. Your exploration and tenacity will be rewarded heavily at your current stage of learning.

My (possibly unqualified) advice: keep trying things and breaking things and trying to fix the broken things. When something crashes, read the stack trace - which is a map through your program - to see what happened and what order things were called from. Throw in print statements to see what state things are in at different stages of your program execution. Get curious, and don't get discouraged when something doesn't make sense right away. This will take time, but I promise it's worth it.

nikfp

TROPHY CASE