mellery451

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.

it's also generally preferred because it can avoid certain narrowing conversions in construction: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

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.

..yes - in particular, boost::asio which will provide a sensible transition to std::net (networking TS) when it's available.

I think visit is what you want (http://en.cppreference.com/w/cpp/utility/variant/visit), unless I misunderstand what you mean by "pattern match"

> 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.

looks interesting, but I'd rather have a tool that exposes a data API so that it can be plugged into vim/emacs

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.

Classless and unprofessional in all respects. We can all learn by their example how not to treat candidates.

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).

just my $0.02

most of this is stuff Herb (and others) has been promoting for years...and It's great to see it codified in one place.

you can try looking at:

https://www.reddit.com/r/somebodycodethis/

https://www.reddit.com/r/SomebodyMakeThis/

...who knows, you might find something interesting to spark your imagination.

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).

YouCompleteMe (https://valloric.github.io/YouCompleteMe/) is a code completion engine built on libclang and works quite well. If you happen to use cmake for your projects and tell it to emit the build database file (CMAKE_EXPORT_COMPILE_COMMANDS), YCM can use it. As with anything in vim, you don't get this for free - the setup is non-trivial.

a good point - which I why I will be sticking with CMake for my cross-platform build needs.

I've worked in a bunch of these kinds of spaces - all utterly distracting. Turns out I'm more productive in my own quiet space at home. If you are doing this to your workers, give 'em the option to work from home and save the rent.

what I find most interesting is the pro-active safety net for laid-off workers and a culture that permits and encourages people to train for a different job as needed. In the U.S., by contrast, you are expected to feel shame and desperation when you lose a job.

well, in many places DevOps is implemented as "developers on PagerDuty". When I (the developer) have to be on-call for 7 day rotations, phone by bedside, paged at all hours, then I'm most definitely acting as operations - probably NOT what I signed up for.

And, contrary to the stated intentions, I've directly observed developers making crappy, band-aid fixes to ongoing production problems in the interest of "making the pages stop". This is the mindset when you are on call be being paged at all hours.

In theory, DevOps is supposed to put those that can best fix things closest to the problems, but in reality a slight separation from the firestorm of ops actually produces better, more thoughtful solutions in the long run.

The best balance is to have a first tier Ops on-call, 2nd tier engineering on-call, and any alerting issues get attention within 24 hours, moving to the front of the work-queue. But, indiscriminately assigning everyone "pager-duty" rotations leads to lower quality solutions in the end.

where do we go to see what cars you currently have for sale?

maybe get in-touch with the SWE chapter at UCSD (http://swe.ucsd.edu/home.html). I'll bet they will have some events or could arrange some informal tours of interesting facilities on campus.

For many of us, it comes down to -- as Dan Pink describes: Autonomy, Mastery, and Purpose. Very few companies are good at enabling even ONE of these, let alone all three. Startups are among the worst for fostering this kind of motivation.

Without a well-balanced three-legged stool of motivation, a few years is all you are going to be content. Or, like many of us, you will gradually learn to lower your expectations, eventually settling - tolerating lesser situations - for a longer time.

http://youtu.be/u6XAPnuFjJc

Thank you for shining a light on this madness. I've had the same experiences here in SV and these "extreme hiring" practices don't seem sustainable to me.

I've been lately thinking that perhaps we'd be better off with a more fluid style of hiring, say something involving real probation periods after which both parties assess how things are going and decide whether to continue. That approach is complicated, though, by the fact that on-boarding an employee is costly. Perhaps THAT's what we need to optimize.

not many other fields of work where that analog exists, so I call BS. What's the personalized test given to CPAs? Sales? Marketers? You ask about past experience, accomplishments, etc..but rarely put them under the gun to produce on the spot.