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
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
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.
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.
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.
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.
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.
Fearless Salary Negotiation (https://fearlesssalarynegotiation.com) is a book about negotiating salaries after you get an offer. Josh Doody’s book covers communicating with hiring managers, dealing with the dreaded salary question, how to write a counteroffer and more.
The first section of the book covers how to determine your market value.
One thing to be aware of is that companies have pay grades which can affect the size of any raises you get. If you are hired into a company at the top of a pay grade, you may have to get promoted before you can get any raises. Whereas if you start at the bottom of a pay grade, you can get large raises until you reach the top of that grade. This can also be a factor when negotiating salary, because you may need a salary that they cannot offer to you without bumping you up to the next grade.
The next section covers negotiating higher pay when you switch jobs
Getting better at negotiating offers is why I bought this book. Most employees will negotiate less than 20 offers in their career. But a recruiter or hiring manager could negotiate 20 offers in a single year. This disparity is a bigger deal than most people realize because each offer you don’t negotiate could represent a loss of $10,000 a year for the rest of your career. The book includes a few sample emails which I have used to get over $5000 increases on several offers.
The last part of the book is about how to get a raise in your current job.
I have never bothered negotiating raises at my current job. You should avoid any situation where you cannot switch to a new job for more money. Your employer has the structural advantage in this market. You only have leverage when you have multiple offers. Interviewing is a huge time commitment. If you are not going to take the biggest raise you can get its not worth it. My last job search took almost 24 hours of my time for each offer I got. If you stay you will almost always be leaving money on the table and that is after blowing days worth of time.
I recommend Fearless Salary Negotiation to anyone who is looking for another job and wants to get paid more.