The Senior

Titles are a funny thing. Sometimes we like to play them down, and sometimes we like to have big, fancy ones. Banks typically make lots of people "V.P."s so you know you're talking to somebody important. The CEO of my last company said, "you could call me the janitor as long as I got paid more than you." When it comes to developer positions, an often used term is "Senior" and it seems to mean different things at different places.

What is "The Senior"? 

At a previous company, a large defense contractor, there was a technical progression for Software Engineers: Associate -> Engineer -> Senior -> Staff -> Senior Staff -> Principle. It went on from there but not many reached the higher ones. (Remember that previous CEO of mine? ; ) Being a "senior" at that company put you squarely in at a Level 3 Technical position, and was directly related to your experience, education and pay scale. Outside of these extremely large organizations, a "senior developer" means many different things. And it is not consistent among companies.

Sometimes the title is self-defined. If someone thinks they are "senior" and can convince their boss or hiring manager the same, they'll get the title. Some companies have (loosely or strictly) defined criteria for what senior means, and some are too small to think about titles so it seems like people just make things up. I'm looking at you, "Chief Awesomeness Officer at New Startup Company." Everyone there gets a good title because both of you needed cool business cards : )

Is a senior based on experience in years? Skill? A gut feeling - "I know it when I see it." I've seen the title claimed by people that were skilled and/or experienced, but still felt something was lacking. They were good at what they did, but were they a senior in my eyes? Something seemed off, the title did not match.

Trust

To wrap up, for organizations without a defined progression structure, it comes down to trust. What can I trust this person with? 

• new team member/mentee? 
• entire team?
• research project or incubator idea?
• maintain a legacy project that business critical? 
• product roadmap?
• deadline?
• customer (interaction)?

Some people might have skills at some of these, and some experience as well. Ultimately it comes back to the stakeholders, and if they can trust their "Senior" with their product. Placing people in their strength areas is important, and in my opinion, a senior could simply be trusted with more. Maybe more in a few select areas, or just more areas in general. 

In the end, do not worry about titles. Keep working hard and growing your skill set so that you can be trusted with more. A good indication of what you could do is what you have already done (e.g. - What have you done in production setting that earned money?) 

Stakeholders will notice, and are seeking to find, people they can trust with their product. 

Performance Matters

Performance matters. And when we develop code we want it to be lean and efficient. Those algorithm courses we took in college and the study of Big O notation surely lets us write performant software. Algorithms that are fast, using the minimal amount of memory are sure to wow our stakeholders!

[Those of you working in the embedded space can probably skip this entire post. Performance does matter where CPU, GPU and RAM are limited. I cut my teeth for years programming towards and recording Technical Performance Measures on avionics display software. Every millisecond counted and when our load time requirement of "3 seconds" failed because of "3012 ms" - anything is on the table to increase performance. If performance is the requirement, it matters everywhere, and you should care all the time! ]

When does performance matter?

Unless performance is part of your requirements, it doesn't.

Most game and app developers, or those using modern web technologies (front end or server-side), well, performance does not matter that much.

At least, it does not matter that much right now.

When developing a modern system, do not focus on the optimal performance of your code in the first pass. Yes, you might be able to hand code a more efficient sorter than .sort() and you might save a few bytes from your network packets if you minify/uglify your payloads yourself. You might even move an algorithm from O(n^2) to O(n log n) in only a few hours.

The thing is, it just does not matter right now. Until your code is deployable in production, time spent optimizing and tweaking for the sake of algorithm performance is wasted time. Get it working. Make sure it is robust, passes your tests and can be deployed. That is the only time to go back and optimize. Focus on writing readable, maintainable, testable, deployable code first.

Does performance ever matter

For most projects, it probably doesn't. It could be a good exercise to code some whiz-bang algorithm or try to reduce the number of statements or calls needed in a function. Once your software is working and deployed is the time to know if performance matters. Why spend time optimizing something that might change? Or a feature that gets cut?

Consider these things as you decide if might matter:

Human-speed vs computer speed

Computers are really fast. Humans are not. If you are optimizing for something that will be noticed at human speed, don't. Why worry about a list of 100, 1000, or 10,000 items? You CPU will burn through those operations whether sorting or mapping or whatever. If the function you are performing is part of a user interaction, they will not notice the time savings between 157ms and 194ms. And a computer will do a lot in those 37ms. 

How often does this happen

Some functions and data flows happen often and concurrently. Speeding up those could have noticeable gains, even to us slow humans. However, some flows happen very irregularly. We have a special admin action that will gather a certain report. The report is costly to run, but is only requested maybe weekly. If all our concurrent users asked for this report every few seconds, our system would come to a halt! Time to optimize! As it is, the time needed to optimize is not worth the single, transient blip. Let's spend our effort on more worthwhile User Stories. 

Just scale up

Hardware is cheap. Can your current performance metric just be solved by buying a bigger machine? If your DB layer is running slow, is it worth your time to profile and optimize all your SQL statements and maybe rearrange your data tables? Or could you just buy a bigger server? Same for CPU, RAM, Network, etc. Do not sweat these performance decisions too early (after your initial planning) because sometimes a bigger machine will fix a lot of problems. In today's cloud world, a push of a button and little more yearly expense could save hundreds of hours of Dev/QA time. 

How to know if performance matters

Ultimately, you'll never know if performance matters if you are not measuring it. Performance metrics are absolutely necessary to 1) know where to focus and 2) know if it worked! Anyone that tells you "that's slow" or code reviews "that's not efficient" has absolutely no data to back that up! What is "slow"? What is "efficient"? Is there a suggestion that will satisfy this arbitrary feeling of slow? Until you can measure performance, you cannot know what is not performant or if you got better!

For a modern web system, you will see performance losses at the system (and typically network) level more than your code. Making 10 HTTP calls in series? You might notice that. Consider how those can be reduced or run in parallel. Is your DB more efficient with multiple JOINs or separate queries? What user actions are used the most? What are the slow ones? What is most efficient to make stakeholders happy? 

Start measuring and measure as much as you can. Then you'll really know where performance matters.

Using Puppeteer in AWS Node ElasticBeanstalk

Our company project has to send out reports and I like the flow of generating those reports from a web page to PDF conversion. We can reuse the tools and skills we use on our web analytics dashboards to develop the reports, with the added benefit that the reports look exactly like the web pages.

I first saw this flow from PhantomJS, the scriptable, headless browser. Load a web page into Phantom, say "gimme a PDF of that web page", re-configure settings 50 times to get it to look better, and boom!, you have a PDF of that web page. This is what we were using in our NodeJS server until reading this note and running into this issue. So we switched to Puppeteer, a similar project that was made for NodeJS and backed up by Google Chrome team.

Our servers deploy into AWS ElasticBeanstalk, their Node Environment. We haven't the need for containers or ECS yet, though did need a trick to get Puppeteer working in project. Things worked locally, but certain required things were not on the AWS Linux machines we were using, and getting those libraries installed on Beanstalk was a bit of a hassle.

A lot came from this StackOverflow question/answer (which itself came from somewhere else). Ultimately, through some trial-and-error, I created an ebextension config file to allow Chromium to install when Puppeteer is installed for the Node project.

File is below, and locally at .ebextensions/chromiumpackages.config. These run in order, first the yum packages and then the mysterious rpm commands. Note the use of --replacepkgs, otherwise your script will run the first time and fail subsequent times because the packages are already there. Yes, I guess technically we are downloading files and try/failing rather than checking if they exist, but it sure does keep the file simple!

And that's it. This config file runs when beanstalk makes a new instance, and then Chromium installs cleanly when my NodeJS project installs puppeteer. Yay!