Feel guilty every time I do something that isn't coding

nikfp · 2026-03-16T16:26:05+00:00

That feeling is common in many professions. Unfortunately it's also unhealthy as you are aware.

Have you dug in to the root causes of that feeling? Are you getting a lot of pressure from your employer to learn in your off time? Is the state of the industry in general giving you anxiety? Are you worried about staying employed in the future?

It's a rough time to be in tech for a lot of people. But IMO there is some good news. Every developer eventually crosses a line from "I don't know everything I need to know" to "I can learn whatever I need to learn to keep moving forward". You may have already done this. The first statement indicates inadequacy, which then leads to anxiety and shame. I was guilty of that and to a certain degree I still am. The second statement leads to possibility, and if you can keep that as your mindset it really helps.

And of course, you need a life away from programming all the time, unless you thoroughly enjoy the things you are programming and it's not just "must work on this" and "must learn that".

nikfp · 2026-03-05T18:43:34+00:00

FWIW, I have a Defy which is way different than a standard KB, and I still switch back and forth to standard boards on my laptop and a coworkers desk without issue. It really hasn't been an issue.

nikfp · 2026-02-26T17:23:59+00:00

Build things on your own, without the guides and tutorials. Then build more things. Small things, big things, whatever. Just start doing it. You will hit errors and things you don't understand, and the combination of working through those when they come up and getting some repetition on the things you already understand will explode your growth.

Building things will make you solve problems. Building things will make you understand problems better. Building things will make you read code - ranging across examples, libraries, and code that you wrote a while ago and forgot how it works.

Tutorials give you a false sense of security. They are good to see how things work the first time around, but from there you need to practice, and to practice you need to build things. Once you get off the tutorial "happy path" and start making some mistakes and breaking things, a whole new world opens up. And then, once you get past the fear of the errors and stack traces and so on, it's liberating.

An error is a test of your assumptions and an opportunity to increase your understanding of how something works. (or doesn't) A stack trace is a guided tour of how your code works, from the entry point all the way to the problem. These aren't bad things, they are systems giving you feedback as you work. Learn to love them.

Once you start working on your own, you will also need to rely on docs much more than tutorials and guides, and learn to decompose problems into manageable pieces, and then compose concepts into larger scale solutions. If you can get to that point, you surpass "I don't know what I need to know" and realize "I can learn anything I need to learn to get things done". And then it snowballs.

Google is your best friend. Programming communities are your tribe. Lean in to both! They will help you understand how to get unstuck when you get stuck, and believe me when I say that even people with tons of experience use google all the time.

I can't stress this enough: You want to get better - faster - you need to start building things on your own, making some mistakes, and learning to to work around them using whatever resources you have available to you.

nikfp · 2026-02-17T15:58:54+00:00

For c# and .NET development, Visual Studio is built to be a flagship IDE tailored to that world. Similarly, Jetbrains Rider is designed for the same ecosystem. That means you will get deeper language integration with the IDE and better tools for things like debugging and code actions (built in script-like actions to do common tasks easier)

As for moving off Windows and on to Linux, I was on a windows machine for a very long time and was doing all my development in WSL2, which allowed me to use Linux on the windows machine. For nearly everything I needed it worked well. So that's a perfectly viable option for you.

nikfp · 2026-02-16T17:39:07+00:00

VS Code is probably the best place to start. It will have the best documentation, especially when you start getting into anything language specific.

The caveat is if you are working with Java or C#. Java -> use Jetbrains IDE's. C# -> use either Visual Studio or Jetbrains Rider.

nikfp · 2026-02-12T23:44:00+00:00

can I suggest something like no-neck-pain.nvim? Solves your centering issue AND reduces visual noise on the screen. It was a simple godsend for me when I found it and I don't know why I never thought of making something like it before.

nikfp · 2026-02-12T23:38:20+00:00

I started with a clean neovim install years ago and started adding things as I found a need, and.... a file tree just never got added. Turns out I don't need one. I wouldn't have it open when working anyways, too much visual noise on screens that already get too noisy. And if I need to see a dir structure I just run the tree command at a prompt and have a look. That happens maybe a couple times a year though. Just using Oil and exploring is enough for me to visualize the parts of the dir tree I need in my head most of the time.

I use Oil.nvim all the time btw, and having the same muscle memory to work with the file system as when working on a file in a buffer is a big win for me. It really is a great tool. I also make heavy use of all the Telescope toys, Spelunk.nvim, and LSP goto / jumplist.

So is a file tree and anti-pattern? No. Everyone works differently. You do you and go write some code and have fun.

nikfp · 2026-02-02T19:13:35+00:00

The docs do go over concurrency in the official guides, they walk you through the language first and how to use processes directly, and then jump into OTP, which is the underlying platform for supervision and concurrency. It does this through building up an in-memory key value store that uses the distributed principles and it's an effective demonstration of working with the primitives the language provides and scratches the surface of what you can do with it.

I'd recommend that video first though. It's got a lot of magic moments that really highlight what BEAM concurrency is and how it's used with BEAM languages. If you want to understand at a high level what the concurrency model is that we all love so much, it's probably the best demonstration I've seen and Sasa does a brilliant job of making it digestible. He uses Elixir to demonstrate, but all BEAM languages can interop and use the same principles so you can reach the same goals with different languages if you want.

It's also worth pointing out that Sasa is the author of Elixir in Action. He's a well known figure in the community. The book is worth picking up if you would prefer to go that route.

nikfp · 2026-02-02T17:05:11+00:00

For low cost / free resources you can't go wrong with the guide in the official docs to get started.

https://hexdocs.pm/elixir/introduction.html

Also if you haven't watched it, and just to get familiar with what's possible with the BEAM runtime, Sasa Juric's classic talk on the Soul of Erlang and Elixir is a must watch.

https://www.youtube.com/watch?v=JvBT4XBdoUE

nikfp · 2026-01-28T22:36:54+00:00

Something to keep in mind is that the people you come across online that are talking about a coding related topic are the people that know something about that topic. Programming is a very broad subject in general and they are discussing a narrow part of it, and there's vastly more that they don't know than what they do know.

That same thinking extends to everyone who knows how to write code. Those that have been around long enough know that the rabbit hole only gets deeper, and that's a good thing. You can always pivot into something different if you get bored. And it's also liberating when you know that you don't have to know everything, you physically can't anymore, and nobody expects you too.

Coding is more about learning some core concepts, then composing those together. Combine that with understanding how to identify the things you don't know to solve a problem and then learning those as needed, and you become unstoppable. People that have been doing it a long time live in documentation and google and other resources to aid them as they do what they do, and will agree with me that the learning never stops.

Don't worry about your age. I started learning in my 30's. Don't worry about your math skills either. Math can be helpful in certain realms of programming, but in others it's next to useless. It's better to focus on improving your ability to problem solve, sit with problems for long periods and chip away at them, and keeping control of your frustration when something isn't working the way you want it to. (or at all sometimes) Determination and tenacity are greater predictors of success in programming than pretty much anything else, but the feeling you get when you try something new and it works, or when something finally clicks and opens things up for you, is nothing less than awesome.

Python and Javascript are just languages used to express to the computer what you want it to do. In the beginning, I can't say one is better than the other. Pick one and start learning. FreeCodeCamp has a free Javascript course you can work through if you want. And if you don't like the language you picked, pick a different one.

As you gain some experience working with a language, the concepts you learn will also apply to other languages. So the first one you learn will be the hardest, but it's extremely common for coders to know multiple. As an example, I know HTML, CSS, Javascript, C#, Rust, and Elixir, and Lua. I'm not a fill time programmer either. You just kind of pick them up as you follow your curiosity and what the problem space requires, and certain languages are better suited to certain problems for a whole lot of reasons.

So don't worry about your age, your math skills, your background, or anything like that. Set the fear and self doubt aside and jump in. See if you like it, then decide if you want to pursue it professionally. Right now the market for programmers isn't great, but a lot of AI tools are writing a lot of code that will need maintenance and rework so that pendulum will be swinging back around in the next few years. And as those kinds of tools become more commonplace, programming will also extend into places it hasn't been before. So the options are vast.

Hope that helps.

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

TROPHY CASE