2020 Age of the remote conference

At this point, in person conferences with 1000s of attendees are done for the year. Lockdowns are easing in general, but most people won’t be comfortable going to a massive conference with 1000s of people from all over the world anytime soon.

We are likely to be disrupted by this pandemic until spring 2021, by when travel is hopefully back to normal. I’ve been working from home for months now and will be doing so officially until October. 

The thing is conferences bring a lot of value to engineering. It is a great way to keep up with what people are doing in industry and to share your experience. I’ve attended some great conferences and enjoyed diving into the technical depth available at a conference devoted to Spark or Kubernetes. 

For 2020 these kinds of tech talks and presentations have to move online to Youtube and Zoom just like our work has. Fortunately, there are some benefits to running a tech conference remotely. 

A remote conference can be a lot more affordable. You don’t need to rent a big conference venue to host the talks, and attendees save money by not flying to a different city or renting hotel rooms. 

You also can save time because you aren’t traveling. Just like we don’t need to commute to the office, you don’t need to travel to the conference. The conference is wherever you are. 

The technology is also good for presentations and Q&A sessions. Teleconferencing shines in situations where you want to share screens and only a few people need to speak at once. Where it really breaks down is when you want to have a group discussion, it is much harder to interleave speakers. But if we focus on activities with a single presenter or a Q&A where someone asks a question, then stops talking, teleconferencing is almost as good as being in person. 

I think in 2020 we will see a lot of remote mini-conferences. They are really economical to host and the timing couldn’t be better. I like the idea so much I have decided to adopt the TinyConf I was planning for this year into a remote conference. 

Recruiter spam of underpar jobs

As your career progresses recruiters will start to spam you with lower quality jobs. I’ve had weeks where I was messaged on linkedin about a job several times per day. Normally that would be great, except most of these jobs would be worse than the job I already have. 

I’m not looking to make a downward move in my career. At some point I might start a startup or take a position as a cofounder, but otherwise I’m looking to move up in my career. Meaning that I am looking for jobs that are higher paying and higher responsibility. Not jobs that are lower paying and require less skill than my current job. 

Why do recruiters spam these lower quality jobs? Honestly, I think they are just spamming them in general without reading people’s profiles at all. Recruiters are paid on commission and there really isn’t any penalty to them for wasting people’s time other than Linkedin charging them for premium. But its not like I’m going to have a moment of weakness, respond to one of these contract for hire java developer positions and then accept an offer for half of my current pay. 

For now the solution is probably to block these recruiters on Linkedin.

Figure out how to debug everything, kill blackboxes

 Avoid blackboxes in your tech stack. It is tempting to say “oh, this piece of software is acting up, but its not our team’s responsibility its xyz team’s problem”. Or this vendor’s software is acting up, “Guess we have to take 30 minutes off while we wait for it to come back up”. Sometimes this pattern shows up in the use of 3rd party libraries. 

It is tempting to allow the resistance to figuring out another piece of software block you from making progress on your project. But letting yourself take the easy route will slow down your progress as a software engineer. A blackbox is just a piece of software you don’t understand yet. You have worked with and figured out hundreds of programs in your career. This one isn’t anything special. 

Don’t let a bug in the end to end framework prevent you from making progress. Figure out the problem, open a ticket against the team that owns it. If you can make a fix yourself. The last thing you want is to get nothing done because you were waiting for someone else to fix a problem that you could have fixed, but “didn’t have to”. 

If your team has a docker compose stack for local testing, figure out how to get it running. Fix the documentation, test your software e2e locally. 

If there is an old integration test suite that intermittently fails, don’t let those failures block your work. Fix the failures, mock the flakey dependencies, don’t just sit there and let some software waste your time because you didn’t want to put the effort into deciphering how it works. 

Working from home

I’ve been lucky enough not to be laid off yet, and have been plunged headfirst in working from home. Before this pandemic I avoided working from home because I got distracted pretty easily and found it easier to get work done in the office. I’ve typically been a high performer and like to maintain work life balance so falling behind because I worked from home is not an option. 

Now I’ve been required to work from home since early march. The first couple weeks were rough. Working in a new setting, big changes going on in the world, combined to make focus difficult. I fell behind where I wanted to be on several projects. It was all dragging me down.

Late last week, at the time of writing, I made two big changes which seem to be helping a lot. They are getting better sleep and using the Pomodoro technique to focus on work. 

To get better sleep, all I did was start closing my blinds in the evening. I live downtown, so at night there are lots of light shining into my nice large windows. The view is good, but the light degrades sleep quality. I noticed a big difference the first night and have been feeling consistently good this last week.

My version of the Pomodoro technique is to do 40minute ‘sprints’ of focused coding time. This gets me past the initial hump and doing solid work. Then I take a short break and circle back for another round of focused work. This is similar to what I would do in the office, work for a while, then chat with coworkers or go to the lunch room. Except now I just stay in my apartment and stretch or workout. 

https://en.wikipedia.org/wiki/Pomodoro_Technique

Working from home is still a bit rough. But I think I’m past the hump of adapting to it. Now I just want to optimize a few things like my monitors and getting a motorized standing desk. 

Expecting end users to customize the experience is madness

 Don’t do it to yourselves

Don’t do it to customers 

Do the work to make a good product

Enterprise software sucks. Its not bought by the people using it, but by a guy wearing a suite on the 37th floor the day after eating a fabulous steak dinner paid for by Oracle sales guys.  By the time you start using it, it is bought and paid for. Suck it up and learn how this pile of code works. 

Internal enterprise software is another beast. Constantly underfunded, built by interns that just learned object oriented programming, and designed by the CEOs cousin, it is not the greatest. 

Know what will ensure that your internal software is never improved in a meaningful way? Make customizing it the default workflow. Just have every engineer at the company load up a GreaseMonkey script that adds in the features that PAAS should have by now. 

The problem is fixed for the graybeards. Sure, every new employee will spend six months realizing that all the people who are getting anything done have customized the UI so extensively its not recognizable as the same product. 

When they said go use ‘deployment ladder’, they meant use ‘deployment ladder’ with 12 GreaseMonkey scripts installed. Where are those scripts? You might ask, the answer is always ‘in the wiki’. Searching for the name of the thing in the wiki does not result in finding the thing, like it would in google for an open source project.

Having everyone customize the software does not result in a good product. It papers over a shitty UI by fragmenting it even more. After a while no one with any power in your organization realizes there is a problem because they have 50 GreaseMonkey scripts installed, and haven’t looked at the actual ‘base’ UI in 5 years. 

Save yourself millions in on-boarding. Invest in good tools. Put the work into offering a great default workflow. Don’t end up in a situation where the graybeards can’t even understand the workflows the new hires are dealing with.