Links Post

https://presumably.de/monorepos-and-the-fallacy-of-scale.html

Monorepositories are an interesting topic. The more I use similar systems the more I think monorepos are the way to go.

The Product Model vs Project Model

https://nickmchardy.com/2018/12/doing-products-instead-of-projects.html

Nick McHardy writes about how his organization moved from doing ‘projects’ to organizing around ‘products’. Especially interesting for me since I just moved from a project organization to a product organization.

Sensible Software Engineering

https://www.scriptcrafty.com/2019/02/sensible-software-engineering/

How do we get out of the local optimum of software development theory we are in now? We can be somewhat confident that there is a better programming paradigm out there than the modern Java ecosystem. Technically, there is an ideal development paradigm, even if finding it is near impossible. It takes us around 20 years as an industry to explore one paradigm. We don’t know what we can do to find a better paradigm within the constraint of how much it costs to really explore even one.

This reminds me of the multi-armed bandit problem. You want to find the optimal slot machine to play. But you still have to create things as an industry every year. 

Pipelines should automatically reject change-sets that fail the integration tests.

CI/CD is magical when it works. Write your code, open a pull request, get approvals and merge. Then the pipeline takes care of everything from then on. Integration tests are run end to end and UI tests pass. Finally, your change is deployed via a canary release into production. 

My team runs a full CI/CD pipeline, after a Pull Request is approved and merged it is deployed through several stages of integration tests and deployed to production. This pipeline gets a lot of use with around 10 engineers working on it at any given time. Unfortunately, because of how our infrastructure works, integration test failures often break the pipeline. 

Changes do not proceed through the pipeline independently, instead commits build up in front of slower parts of the pipeline, particularly our integration and end-to-end tests. During busy times several pull requests will be working their way through the pipeline together.  

Our integration tests can fail for many reasons other than code changes. A partner team could have a failed deployment that is upstream of us, a configuration file could have been changed, a test account could have expired, and more. When the pipeline does fail, we have to track down what caused the failure. If it was a code change we will revert the commit, otherwise we typically have to work with another team to get their systems working. 

When a pull request breaks the integration or end-to-end test the pipeline will block at that stage. Then we will revert the changes and redeploy the master branch. In the worst cases several commits will have to be reverted and redeployed into the pipeline before it will start working again. 

Fixing the pipeline will often take an entire day as the fix has to move through each stage in the pipeline until it reaches the one that failed. Then there will be a flood of changes as all the commits that built up at the failing stage move onward. 

I would like to fix this, but doing so will likely make the pipeline slower on average or require changes to how our Pull Request workflow functions. 

Prepare notes for Standups

Daily standups are a standard part of the software engineering life. Over the last four years I have had a standup of some kind nearly every workday.

Standup is a ritual, you circle up with your coworkers and take turns trying to remember what exactly you did to justify your salary yesterday. Every third update devolves into a 5+ minute derailment of the meeting that would really prefer not to follow. Then when it is finally your turn you spill out your update as quickly as possible. Only to slowly realize 3 minutes later that you forgot to mention half of the things you did the previous day. 

The solution to standup is pretty simple.  Just take notes.

I keep a checklist of tasks in the Mac notes app. I check off the item when its done. Then in standup all I do is read through my list. 

Just keeping a little list of tasks makes it easy to remember what you did for standup. It is easy and will save you the embarrassment of not having anything to say to justify your salary during the meeting.

A Certification is not the same as having a skill 

People often ask on r/cscareerquestions, “Can I just get this Java Certification instead of doing a Bootcamp or getting a CS degree”. And the answer is that the Certification is not going to help you as much as you think it will. Computer Programming is still a young field, gate keepers are just not that important yet. Becoming a Real Estate Agent requires you to get a License or Certification from the State certifying you to buy and sell houses for people. There is nothing like that for Computer Programming. Anyone with any amount of skill or experience can declare themselves a ‘Software Engineer’. There is no governing body which can ‘certify’ your skills. The current standard is Whiteboarding problems and timed hackerrank.com questions. Your return on investment from investing time into hackerrank.com will be much higher than getting a Certification. 

How Software Engineers demonstrate their skill to the market is through whiteboarding questions. Get good at that first then worry about Certifications. 

Does this make Certifications worthless in Software? I don’t think so, but it is not going to be worth it for junior developers trying to break into the market. One of my employers paid for me to get the ‘Certified Kubernetes Administrator’ certification from the CNCFF. Why did they do that? So that they could qualify as a CNCF partner organization and get free marketing and a better aura of expertise. 

I put that certificate on my resume, but it has not gotten me any Kubernetes jobs. If your company is going to pay for a certification go for it. Otherwise, I do not think it is worthwhile for you to pay for it personally. 

Getting into Software Handbook Released!

The Getting into Software Handbook has been released on Amazon. This handbook is a guide to becoming a Software Engineer with a non-traditional Computer Science background. I learned to program when I was 21 and had a lot of catching up to do to enter the industry. This handbook covers my experience and thoughts on getting into the Software Industry.