Interviewing for "programming" roles

 I've been reading Erik Dietrich's blog, and it's reinforced a lot of things that I either already knew, or had bubbling below the surface on corporate politics.  I'd highly suggest you give his blog a read, and his book is pretty good too.  I'm going to focus on what he says about interviewing on this post (and maybe more, depends on how long this runs), then I'll try to address the larger issues of corporate politics that he scrutinizes and how I see them.

Let me put up front that, though I too hypocritically use the same techniques when I've had the occasions to interview people, I think that he's spot on in his assessment of the process, and there has been at least one study (it's the 3rd question in, and there's no data just high level on what they found, the second link provides slightly more data) and many more anecdotal agreements with him (or he with others, I don't know or care which came first).  Erik's suggestion: "Just don't do it".  I haven't had to interview for a few years now, and the last one I did have thankfully didn't include any of the interviewing anti-patterns, though I've had more than my share of those over the years.  Erik expounds on his advice in case you get stuck in one of these anyway.  I haven't tried any of his tactics, but if I ever go through one of these again, which isn't likely at this point, I'll be sure to let them know that "I’m afraid that your company isn’t a great fit for me at this time.  But if you wind up brushing up on your interviewing process and making improvements, feel free to reach out to me again for consideration."

Working Remotely - 2

 In my previous post I mentioned timers, something I personally have found useful is the pomodoro timer.  You don't need to buy a (not so) fancy tomato timer, just something that you can use as a 25 minute timer.  This fits well with flow and getting up twice an hour.

Have a routine

I start my day off with my morning rituals (brushing teeth, grooming, shower, coffee, etc), then I do my morning interval run, and some stretching/calisthenics before I settle in for work.  I take my lunch at the same time, and have a schedule for meetings.  Try to have a structure to your day, this makes following your get out of the chair timer a little easier as well.

Have a good great chair.

This one is critical if you have a screen time job.  If you're going to be spending 8 hours of your day sitting in a chair, it makes sense to have a great chair.  IMO this is highly personal and anything I recommend is really not going to help you.  Personally I've looked at and tried the Aeron chairs and I'm not a fan, though a lot of people seem to be.  You need to go to an office or furniture store and sit in them before you pick one.  This will take time, but it is well worth it to have a chair that you are comfortable in.

Try a convertible standing desk

Anything that keeps you from sitting for long periods is good, but I've seen research that standing on one position for long periods isn't much better, which is why I said convertible.  It doesn't have to be the whole desk, if you've already got your office furniture there are converters that will raise your monitors and keyboard/mouse just as effectively as the moving desks will, and may be more convenient.  I'm not personally a big fan as the experience I've had with the full desks has been negative (they seem to break easily), but if either solution helps you go for it.  Personally getting up every 30 minutes and walking around does better for me.

I think I'm going to wrap up there, as anything else I can think of seems to be highly situational and won't necessarily apply to a majority of people,  if I think of more later I'll do additional posts to cover them.

Working Remotely

 Hopefully this will end up as a series of posts, I know lots of people have been writing about this since the advent of COVID-19, but I've been doing this for about 6 years running now, so hopefully I can offer some more insight and what works longer term.  I come from doing this as a programmer, so if you're in another industry and see something that may work differently for other areas please leave a comment.  I will also include what I feel is the obvious in order to make this a hopefully complete recommendation.

Have a separate space where you work

This is probably the most obvious and most stated piece of advice, but also likely the most important.  If you want any kind of "work-life balance" then you need to, well, separate work from life.  If you're working in the spaces where you do the rest of your life, it will be hard to stop working.  If that's your thing, hey, go for it, but after doing that a long time I can say there is a definite benefit to being able to finish work and leave that space behind for the rest of the day (whatever your day may be).  People working in office have an obvious separation, though work has been creeping more into life in that respect lately as well with on call, having to be available for production issues, your boss just feels like calling or texting for whatever reason.  I would highly recommend you still set definite boundaries in this area, i.e not taking work calls after hours when your not on call and addressing them the next time you are in "work hours".

Keep your work space separate

Don't do things in your work space like eat, sleep, play, whatever.  Keep that area for work.  It will be tempting to do these things (except maybe sleep, but I've done that too), but that makes for the slippery slope effect.  Strive for what astronauts do in space, "clean separation", keep your work shit in the work zone, everything else outside.

Keep your work area clean

Hopefully you did this when working "in the office", and you should continue to do this in your home office.  It will help keep you in "professional" mode, whatever that means for your job.  Take some of the time you save every day from eliminating your commute and use it to keep your office clean.

Get up and move

This is a tough one for me personally.   As a programmer I get "in the zone" and I can and do ignore everything until I finish what I'm working on, if that's 20 minutes or 6 hours.  Sitting for long periods is terrible for you physically and you need to keep yourself active.  I try to (work in progress, still) get in a short interval workout early in the morning (after my other rituals, coffee, stretching, etc).  Use some kind of timer, and DON'T IGNORE IT.  As soon it goes off, whatever you're going, GET UP.   If you condition yourself to ignoring your timer, you're not going to do what you need to, and you need to get out of the chair at least every 30 minutes.

And my timer just went off, so I'm going to end this post here and continue another day :)

Back to basics (of Javascript?)

I've seen a lot written recently about returning to the "basics" of javascript (some of these do make good points), and some rebuttals to this notion, and some that take my PoV.  The "return to basics" camp appear to me to be relative newcomers to the software industry (by relative I have 25 years doing professional development, and another 10 or so before that of hacking things on my own).  I think these people didn't have to come up through the age of learning assembly, learning c/c++, and then, thank god, having the higher level languages become available.   I've seen some say that javascript is the assembly language of the web, and if that's true, why the hell would we want to write in it if there is a higher level language (typescript, web assembly can be written in almost any language at this point) available.  You don't want to go back and write programs in assembly (alright, maybe some do, but they are a special breed) when you have c#, python, java, etc available, right?  That's like saying "Ok, I have a hammer, let me go build a skyscraper with it."  You're going to need a few more tools in order to do that, and if you don't buy them, you're going to have to make something someone else has already made.  Yes I know a lot of people will complain "but tool XYZ doesn't do exactly the thing I need", well, use the tool for what you can, and put pieces together to make something, that's what engineers and architects do.  They don't stand around complaining "Oh, this circular saw has a 12" blade, I have to have one with a 12.5" blade.  You make it work.

I particularly love this quote

"Software should be developed using least amount of complexity, dependencies, effort and using fundamental tools that have been and will be here for the next 20 years."

Who in the hell thinks their software is still going to be running in its current form in 20 years?  If by some miracle it is, then it's the problem of the people running it to make sure the same tools and assumed environment are available to run it.  You don't see people expecting software from windows XP to continue to run on Windows 10 (well, maybe some people do, but hey it takes all kinds in this world).  The underlying hardware and software have just changed to much for that to be feasible.  Yes, you can run a VM that will probably get you 90+% of the way there, but some programs were written to directly access hardware and that hardware just isn't around any more, or make assumptions about memory allocation, there are all kinds ways the old programs just won't work.

Another one I like:

You take a risk whenever you bring in 3rd party code. This risk is reduced with tried and tested libraries/frameworks, but never truly eliminated. If you can get away with writing code yourself or with your team, you can reduce that risk and maintain a codebase that you know in and out.

What is the risk that we're taking?  That the code will disappear?  Unlikely for many reasons.  The risk that the code won't do exactly what we want?  Use it for what you can, or fork it and make it do what you want.  I would propose the bigger risk is creating something on your own where you don't have the time to think through all the ramifications, whereas you could be helping a group (hopefully) of people who are already working on the problem, adding your knowledge to theirs.  That's what OSS is all about really.

I'm not saying don't learn the basics and the underlying technology and the context in which these were built, learning this will absolutely make you a better programmer/developer in general, but learning something doesn't mean you are going to or should use it in your day to day activities.  I took 4 years of Latin in high school with no pretense of actually speaking it, but it is extremely useful as a lot of languages derived from it, and I can very often get a basic understanding of a word based on its derivation from Latin.  So please, learn all you can about computer science and the history that brought it to its current form, but please don't re-invent the wheel whenever you have to travel somewhere.

I know people don't like change in general, but if you're any kind of developer/programmer, you better thrive on it, and love it, because the rate of change is just going to keep on increasing.  No, you're not going to be able to know everything, pick some areas that you like, and learn them, and keep learning them.  You will get paid for knowing them, if that's your goal.  If you don't like change, go learn Assembly or FORTRAN or COBOL.  I'm sure some bank will want to know you.

Sorry for the rambling, I meant to focus on Javascript, but branched off into general programmer stuff pretty quickly.

Agile workflow and how it's (not?) used

I've been thinking about the Agile workflow recently, mainly due to pains employers I've worked for have had with implementation and delivery.  I've seen a number of places that miss the very first tenet of Agile:

Individuals and interactions over processes and tools

So many places I've worked for place far more stress on the processes and tools, i.e. how do we measure what Agile is doing for us, from Kanban boards to scrum sprints, the focus seems to be on measuring velocity, not on improving velocity.
More places seem to understand point 3

Customer collaboration over contract negotiation

I have worked for very few places that try to turn the thumb screws on over the letter of a contract, and most clients seem to understand that things evolve as they are developed and don't have a problem with updated payments.
Weirdly however lots of places still don't get point 4, even though they do get point 3:

Responding to change over following a plan 

Once a plan is in place, they will try to stick to it until the end beyond all reason.  I'm very curious as to the cause of this, or if it's just me seeing this.

Why you should put package-lock.json in source control

Simple, eliminate the "works on my machine" response from developers:

package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.

This will keep all the installed dependencies the same when you do npm i. If you don't, any packages you have in package.json will get their dependency tree based on what the package you're using specifies, i.e. it could be latest compatible (@^x.x.x) or anything.  And without a package-lock.json you're at the mercy of what your dependencies specify.

Angular, Angular, more Angular, and Redux

I've been working with AngularJS and Angular 6 for 2 years and almost 1 year now respectively, and I do enjoy them both.  I'm also loving Redux, but wish I had known about it when I first started with the AngularJS project, it would have saved me a lot of headache with client side state.  I'm converting the project over, but it's slow going with the amount of work.  I'm also very glad for the Pluralsight courses on them (shameless self plug), the Angular NgRx: Getting Started course by Deborah Kurata and Duncan Hunter is very good for, well, getting started.  I already knew a bit about redux and working with it, but the effects chapter was very useful, and the Architectural Considerations chapter on container presentational pattern I liked a lot.  I'm watching a course on unit testing, but I'm still having difficulty with figuring out what to test on a UI layer.  I'm used to writing tests for things that have logic in them, and I try to keep the logic out of the UI layer.  I can where testing services and probably the container components would be useful, but I don't know about testing a presentational component, it would seem to make for brittle tests, hopefully the videos will be informative in that area.