one topic not mentioned is creating refactoring tools. My sense is that LSPs generally have the advantage here because they have the full parsed tree, but I suspect it would be possible to build simple syntactic refactorings in TS with the potential to be both faster and less sensitive to broken syntax.
agree - what's more, the author is really talking about blaze, where everything "just works" because there are massive dedicated resources maintaining it. He literally admits that he likes the copy-pasta-no-think-about-it:
> Surprisingly, I didn’t need to fiddle with blaze, nor did I have to understand how it worked. I could copy some build targets and edit the dependency list, and the build worked as expected.
Sure, systems that just work are great, until they break.
bazel on the other hand, not so much. Heaven help you if it doesn't support your use-cases - you will wish you had Google to maintain your build.
yes - I use coc + clangd and there is no comparison with cscope. The level of accuracy you get with clangd is significantly better than tags/cscope. The main thing you need to make clangd work properly is an accurate compile DB. Yes, you can general/coarse compile settings, but the accuracy drops off for a project of any size. I also suggesting staying reasonably up-to date with clangd releases since they are adding important features/fixes with each release.
as to how clangd sees your current translation unit, it comes down to the compile_commands.json (which is per-TU settings) or the more general compile settings in the config file(s) (https://clangd.llvm.org/config.html). If you need to change your TU settings, you could have a simple scheme that symlinks compile_commands to different files depending on build type and then restart the server. I've not typically needed to do this (I tend to just stick with a debug build compile DB...), but it's something you could do pretty easily.
There is one clangd process per editor process. If you have multiple projects with distinct compile_commands you might be able to come-up with a scheme to switch between DBs and relaunch clangd. Alternatively, you could try merge all compile_commands together, but I'm not sure the effort would be worth it -- just running separate vims seems like it makes the most sense to me.
For switching between branches, you can typically regenerate the compile commands DB pretty easily (if you use cmake...), but it's really only necessary if there are big differences in files and/or compile settings between branches.
> Successful remote workers are disciplined and self-motivated. No boss is eyeing them from across the office to see whether they’re working. They alone are responsible for structuring their workdays.
This sounds like precisely the kind of person I want to work with, regardless of whether they are remote or co-located.
> I say let people work from home but make sure they have the option of an office.
...or provide a stipend to be used to help pay for local co-working spaces, if that's your preference. I can certainly understand how some people might need alternatives to the monotony of WFH, but making everyone commute to some crowded business district/downtown is whole other set of nuisances and inefficiencies.
I studied to be an S.E. for 7 years (undergrad/grad) and practiced for a little over a year before I gave it up for software. First, the pay was atrociously bad given they years of schooling. Seriously, I couldn't justify doing it if I didn't absolutely love it because I was barely getting by.
Furthermore, S.E. in practice is pretty boring -- lots of repetitive calculations. Yes, there is room for software automation, but that kind of automation is never rewarded - so much of the tasks just seemed to be coordination and paper shuffling. Beyond that, working on projects often meant waiting years to see anything come of it - think about how long it takes to get a large project from concept (design) to completion. In most markets it's a very long timeline.
That said, if I were to have stayed in S.E. I would have focused on smaller projects (with shorter timelines) and I would have tried to specialize in field engineering (being on-site) since that's where most of the real problem solving happens.
Luthiery specifically for me - it's a hobby currently and the thing I think about the most when I'm programming. The tooling and jig making aspect of woodworking is also very satisfying to my engineering tendencies.
On the other hand, strawberry perl (http://strawberryperl.com/) for windows solved this by simply including a free toolchain (gcc). The gcc compiler for windows is hardly typical, but it was an interesting choice so that they could have more control over the build environment.
That said, I think MS can/should make installing a toolchain easier than they do. It ought to just be another component of the OS that you can choose to have or not have. Supporting different versions of the compiler on one box is a more advanced use-case that advanced developers can deal with - but each rev of the OS should have the "default" toolchain that installs seamlessly.
it's the false positives that worry me more - that is, the well-practiced whiteboard coder who cannot actually design a maintainable system or the sociopath or brilliant jerk who nobody can stand to work with.
I worked on a large to-UNIX migration using Mainsoft long ago. It was amazing how complete their win32 solution was, but it all felt so wrong. Using cross platform libraries from the get-go and NOT relying on single platform architectural components (like COM) is ultimately a better way to go.
Here are some of my reasons for running tmux inside of iTerm:
* easy layout of panes (windows) in fullscreen mode. I have tmux macros setup to quickly get different pane layouts -- e.g. 65% left, then two vertical split panes in the remaining right 35%. Typically I run vim in the larger pane and then have two other panes for various other CLI stuff on dev systems. I have a number of other preconfigured layouts depending on what I'm trying to get done.
* tmux session can be detached/reattached. I've on occasion had iTerm crash or I've accidentally quit it (cmd-Q). With tmux, my session is still running, so I just restart iTerm and reattach...everything back where I left off. There is even a new-ish plugin for tmux that lets you save tmux sessions so that you can restore after restart. The reattaching also makes it low-overhead if/when iterm wants to update itself (admittedly rare).
* Once you get used to tmux navigation keys/commands, they will conceptually work on linux systems as well if you run tmux (more portable muscle memory).
This sounds like a brilliant idea. I hope that you are also including homework assignments that cover (1) communication skills (especially WRITTEN communication) and (2) personality. In my experience, those two areas are far more critical to success than raw coding skills. Also, everyone should pass the "no assholes" test, if there is such a thing.
I hope that you expect the same amount of prerequisite work for all of your candidates (marketing, finance, sales).