• 0 Posts
  • 55 Comments
Joined 2 years ago
cake
Cake day: July 4th, 2023

help-circle
  • Sorts? Not tabs in the way you’d expect but it’s default ones can be sufficient

    Honestly though once you get pretty good with hotkeys you stop using tabs, for all intents and purposes harpoon is tabs, but better, and without the UI. You just mentally usually pick harpoon keys that make sense to save jump points to, like I’ll harpoon FooController.cs to c and FooService.cs to s and FooEntity.cs to e and so one

    And the I jump around with those keys. Usually when working I only need tops 5 harpoon or so for a chunk of work.


  • I still boot in sub 1s so I don’t know what you mean by “bloated”

    Lazy allows you to boot ultra fast by loading stuff in the background later, so “bloat” doesn’t matter

    nvim-dap does literally nothing until you trigger it, so it’s only impact on my startup is like 3 hotkey registrations :p

    It’s a perfectly fine debugger, works great. The fact I can telescope search to fzf my stack trace actually kind of makes it superior? Like you can’t do that sorta stuff in any other IDE I know of

    Also all my navigation stuff like telescope/harpoon/etc still apply when debugging, so I can literally debug faster jumping around the stack trace with hotkeys.

    Neovim doesn’t get any less awesome when it comes to debugging, a lot of it’s power still applies just as much haha


  • A lot of them are dependencies of other plugins.

    Stuff like icons support, and every little feature. Neovim is extremely minimalist to start, so you need plugins just to get something as simple as a scrollbar lol

    Things like git status of files and file lines, all your LSPs, syntax highlighting (for each language you work with), file explorer, you name it, there’s a lot.

    But what’s nice about nvim is for any of these given features, there’s numerous options to pick from. Theres probably a dozen options to choose from for what kind of scrollbar you want in your editor, as an example.

    So you end up with a huge amount of plugins in the end, for all your custom stuff you have configured.

    You have to setup yourself (though theres a lot of very solid copy pasteable recipes for each feature):

    • Scrollbar
    • Tabs(if you want em)
    • bookmarking
    • every LSP
    • treesitter
    • navigation (possibly multiple of them, I use both a file tree, telescope, and harpoon)
    • file history stuff
    • git integrations, including integrating it with the numerous other plugins you use (many of them can integrate with git for stuff like status icons)
    • Code commenting/uncommenting
    • Code comment tags (IE TODO/BUG/HACK/etc)
    • your package manager is also a package (I like lazy for wicked fast open speeds, neovim opens in under 1s for me)
    • hotkey management (I like to use which-key)
    • prose plugins (lots of great options here too, I use nvim for more than just coding!)
    • neorg, so I can use nvim for taking notes, scheduling stuff, etc too
    • debugger via nvim-dap
    • debugger UI via nvim-dap-ui
    • lualine, which is a popular statusline plugin people like to have at the bottom of their IDE for general file info
    • new-file-template which lets me create templates for new files by extension (IE when I make a .cs file and start editting it, I can pick from numerous templates I’ve made to start from, same for .ts, .lua, etc etc)
    • git conflict, which can detect and work with detected git merge conflict sections in any type of file and give me hotkeys to do stuff like pick A / B / Both / Neither, that sorta stuff

    The list goes on and on haha



  • API is just the term for “the surface of something that’s been exposed to you to interact with”

    Libraries, websites, tools, etc all have APIs, it’s just the general term for “this thing has something we can interface with”

    A library is a bunch of code someone else wrote.

    A package is when you use a tool to bundle up a library to make it easier to distribute to other people, usually adding a version # to it, and adding it to so.e popular package manager network so millions of people can find your package easier.

    A framework is a term for a very big cohesive library, with an advanced api, that does a whole bunch of different things that all have stuff in common. Basically a firework is a huge library that provides many many different things to do that all have stuff in common.

    Game Engines for example are frameworks.

    A library of tools to make a bunch of different website components that all work well together and have stuff in common is a framework.

    Etc etc. It’s a bunch of code that doesn’t do anything in it’s own, but provides a bunch of modular pieces you can assemble into something.

    Think of a framework like buying a big box of lego. It’s not anything specific yet, but you can assemble all those pieces together to make infinite different things.




  • They probably do use lots of NoSQL DBs too, which perform better for non relational “data lake” style architectures where you just wanna dump mountains of data as fast as possible into storage, to be perused later.

    When you have cases where you have very very high volume of data in, but very low need to query it (but some potential need, just very low), nosql DBs excel

    Stuff like census data where you just gotta legally store it for historical reasons, and very rarely some person will wanna query it for a study or something.

    Keep in mind when I talk about low need to query, the opposite high need us on the scale of like, "this db gets queried multiple times per minute’

    Stuff like… logins to a website, data that gets queried many times per minute or even second, then sometimes nosql DBs fall off.

    Depends what is queried.

    Super basic “lookup by ID” Stuff that operates as just a big ole KeyValuePair mapping ID -> Value? And thats all you gotta query?

    NoSql is still the right tool for the job.

    The moment any kind of JOIN enters the discussion though, chances are you actually wanna use sql now


  • Usually it’s a case of a well thought out decent post, but then you scroll down to comments and it’s “men are trash” and etc, so you end up with a bunch of fighting, which detracts from the original point.

    Prolly would be better if “comments on this are disabled” was more common practice.

    Or if administrative systems actually punished people heavily for saying stuff like “(any group of people) are trash”


  • Might wanna read it again, it’s right there :)

    The best architectures, requirements, and designs emerge from self-organizing teams.

    It’s an incredibly critical part companies love to completely ignore.

    If you assign devs to teams and lock em down, you’ve violated a core principle

    And it’s a key role in being able to achieve these two:

    Agile processes promote sustainable development.

    And

    The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

    This is talked about at length by the likes of Fowler, who talk about how locking devs down us a super fast way to kill sustainable development. It burns devs out fast as hell.

    Note that it’s careful not to say on the same project


  • That’s actually a pretty important part of its original premise.

    It’s a big part of why scrum meetings were a thing, as the expectation was any curious dev could just join in to see what’s up, if they like.

    Not tying devs down to 1 specific thing is like the cornerstone of agile, and over many years of marketing and corporate bastardization, everyone had completely forgotten that was literally the point.

    The whole point of the process was to address 2 things:

    1. That client requirements can’t easily be 100% covered day one (But you still need to get as many as you can!)

    2. To avoid silo’ing and tying devs down to specific things, and running into the one bus rule (“how fucked would this project be if <dev> got hit by a bus?”)

    And the prime solution posited is to approach your internal projects the same way open source works. Keep it open and available to the whole company, any dev can check it out, chime in if they’re familiar with a challenge, etc.

    One big issue often noted in non-agile companies (aka almost all of them) is that a dev slent ages hacking away at an issue with little success, only to find out far too late someone else in the company already has solved that one before.

    An actually agile approach should be way more open and free range. Devs should be constantly encouraged to cross pollinate info, tips, help each other, post about their issues, etc. There should be first class supported communication channels for asking for help and tips company wide.

    If your company doesn’t even have a “ask for help on (common topic)” channel for peeps to imfoshare, you are soooooooo far away from being agile yet.


  • I’ve literally never actually seen a self proclaimed “agile” company at all get agile right.

    If your developers are on teams that are tied to and own specific projects, that’s not agile.

    If you involve the clients in the scrum meeting, that’s not agile.

    If your devs aren’t often opening PRs on a variety of different projects all over the place, you very likely aren’t agile.

    If your devs can’t open up a PR in git as the way to perform devops, you aren’t agile.

    Instead you have most of the time devs rotting away on the sane project forever and everyone on “teams” siloed away from each other with very little criss talk, devops is maintained by like 1-2 ppl by hand, and tonnes of ppl all the time keep getting stuck on specific chunks of domains because “they worked on it so they knpw how it works”

    Shortly after the dev burns out because no one can keep working on the same 1 thing endlessly and not slowly come to fucking losthe their job.

    Everyone forgets the first core principle if an agile workplace and literally its namesake us devs gotta be allowed to free roam.

    Let them take a break and go work on another project or chunk of the domain. Let them go tinker with another problem. Let them pop in to help another group out with something.

    A really helpful metric, to be honest, of agile “health” at your company is monitor how many distinct repos devs are opening PRs into per year on average.

    A healthy company should often see many devs contributing to numerous projects all over the company per year, not just sitting and slowly be coming welded to the hull of ThatOneProject.




  • Yup, I usually have it set to the slowest setting when typing.

    I find I work much better and can think clearer while walking, as it keeps the blood flowing and makes me feel more awake and engaged.

    If I have a tough problem I’m trying to work through I turn the speed up to a faster pace and sorta just work through it in my head while speed walking, often this helps a lot!

    During meetings when I’m bored I also turn the speed up a bit.

    I often get around 10k to 12k steps in a day now.

    Note I don’t stay on the treadmill all day long, I usually clock a good 4 hours on it though.

    Then I take a break and chill on the couch with my work laptop, usually I leave my more “chill” tasks like writing my tests for this part, and throw on some Netflix while I churn all my tests out.

    Highly recommend it, I’ve lost a good 15ish lbs now in the past year since I started doing it, and I just generally feel a lot better, less depressed, less anxious :)


  • I have heard of jupyter but am not familiar with its nuances.

    But doing python dev with neovim is very doable, it uses the same LSP I think.

    I personally have a dedicated dev machine running debian that has everything on it, including nvim configured.

    I SSH into my dev box from other machines to do work, because neovim is a TUI it “just works” over SSH inside the terminal itself, which is what I like about it.

    It feels good to just

    1. SSH into my box
    2. tmuxinator my-project-name

    And boom, 4 tmux tabs pop open ready to go in the terminal:

    • nvim (pointing at the project dir)
    • lazygit already open
    • nvim (pointing at my secrets.json file elsewhere)
    • an extra general console window opened to project root

    And I can just deep dive into working asap in just those 2 steps, it feels very smooth.

    I often can even just do tmux a (short for attach) to just straight re-open whatever session I last had open in tmux, instantly jumping right back into where I left off.


  • I try and start using it for basic tasks, like note taking, to get used to its interface and basic commands like :w and :q, as well as switching between insert and cmd mode.

    Once you are familiar with switching between modes, copying, pasting, etc, then you probably will wanna Starr learning it’s lua api and how to load in some QoL plugins. Basic stuff like treesitter, telescope, and nvim-tree are good places to start.

    Once you feel comfortable with swapping between files with telescope and configuring plugins, I’d deep dive into getting an LSP up and running for your language of choice so you can actually code.

    In the interim I’d recommend getting comfy with using tmux in your terminal, try and open new tmux tabs to do units of work instead of constantly cding around.

    I like to keep 4 tmux tabs open for a project:

    • nvim
    • lazygit
    • secrets file open in nvim (usually my secrets file is in another dir so it doesn’t check into git)
    • a general terminal tab for running commands

  • From my experience the only big changes I’d say I made overtime are:

    1. Font size bumped up

    2. Switched to neovim from visual studio, which took like a year to relearn my entire workflow (100% worth it though)

    3. Switched from multiscreen setup to one single big screen (largely due to #2 above no longer needing a second screen, tmux+harpoon+telescope+fzf goes brrrr)

    4. Switched to a standing desk with a treadmill, because I became able to afford a larger living space where I can fit such a setup.

    If I were to do this meme though it’d mostly be #1, there just came a day when I had to pop open my settings and ++ the font size a couple times, that’s how I knew I was getting old.


  • Nowadays it’s less of an issue with docker and whatnot.

    Just set the image to refresh every night at midnight and if they tried to make manual changes it’ll just revert back to its original state at midnight.

    Customers don’t really get direct access to deployed code now, it’s buried under like 4 layers of abstraction on most CDNs now.

    Simply deploying to azure already smears multiple layers of access control and RBAC overtop that it’s hard enough for me, the dev, to answer the question if “what is actually deployed atm?”, let alone for the customer to get in their and meddle.