Remember your first job? It might have been washing dishes somewhere, or collecting carts at the grocery store, or replacing tried-on items at the clothing store. Whatever the job, it was probably characterized by a low amount of responsibility.
If put your career progression on a chart, it might look something like this:
I’ve written before about how various commercialized forms of “Agile” development completely stripped the original agile manifesto of everything it was supposed to be. A group of people fed up with the software development status quo got together and decided there had to be a better way, and put together the now famous statement.
It didn’t take long before a multitude of people and companies stepped in with a way to make money off of it and started selling systems and training and all kinds of stuff that inevitably turned the agile movement into the exact opposite of what was actually intended.
Continue reading “Do you need product managers at your software company?”
Many companies do some form of software development. It might be software that is offered to others in the form of SaaS, it could be a team developing internal tools, or it could be a smaller non-tech company with a bunch of excel macros that run the back office.
Why software is built, how software is built, and the attitude towards the process can differ significantly between different types of companies. Major differences can include developer pay, influence over company direction, internal prestige, etc. There’s nothing wrong with a job writing software at a non-software company, but developers and company leadership alike should understand the differences and help make sure to adapt.
Continue reading “So you develop software. Are you a software company?”
Everyone loves the delivery of new software features. Users appreciate the added value. Developers thrive on building new things. Companies want to strengthen market position, earn more users, and charge more.
While not as glamorous, maintaining software is just as important. When maintenance is ignored, adding more features becomes more and more difficult until forward progress grinds to a halt. Companies that consistently move their software forward are just as good at managing maintenance as they are at managing the development of new features.
Every company has a “Maintenance Quotient” that represents their effectiveness in performing maintenance on their software:
Software development estimates are often a major point of contention and misunderstanding. These problems are almost always rooted in participants having different language, expectations, and assumptions about the process. How many times have you seen something like the following?
Stakeholder: “When will that feature be done?”
Developer: “What do you mean? I finished that code last week.”
Stakeholder: “Uhhh… Nobody told me. Thanks! I’ll let our client know it’s ready.”
Developer: “Oh, well it’s not deployed yet so you’ll need to wait until that happens before you tell them they can use it”.
Stakeholder: “…”
There are multiple communication problems evident in this example, capped by the fact that neither party has the same idea of what it means for a feature to be “done”. It’s not that either party has the wrong definition, they just haven’t communicated well enough to understand each other.
Continue reading “Collaborative Software Development Estimates”
I’ve been intrigued over the years watching various machine learning techniques steadily progress. Unsurprisingly, some of the advancements that are most apparent are around artificial image generation.
For a long time, Google and others would release videos and blog posts showing what they were working on, and us mere mortals would watch in awe from a distance. Then DALL-E came along with a public beta, and the general public got an accessible tool for anyone able to pay the reasonable fees associated. Since it can take several tries to generate the image you are looking for with these systems, it’s definitely not a cost-free system to use.
The next iteration in machine-generated imagery is here now, arriving as Stable Diffusion by Hugging Face (https://huggingface.co/blog/stable_diffusion). This is a pre-built, freely available model where all the hard and expensive work of training is done. Anybody with a modern, gaming-ready graphics card who is comfortable running a few commands in the terminal can get it up and running.
As tends to happen with useful open software, a community has already cropped up around this tool. The community has made Stable Diffusion easier to use, and has adapted it to multiple hardware platforms. Support was recently added for the Apple M1 chip and its integrated GPU, so I had to give it a try.
My verdict after 2 days of using it: I can’t remember the last time I have had this much fun!
Continue reading “Playing with Stable Diffusion”
A desire for control is a core human trait. We all want to have control over our environment, control over what happens to us in our day-to-day, and control over our future.
We want relationships that we can influence for the better. We dream about a financial state where we can choose what we want to do with our time and money. We build personal routines that bring us fulfillment.
Autonomy has repeatedly been shown to be one of the single biggest drivers of professional satisfaction. We exert a lot of effort to affect who we work with, what we work on, and our prospects for upward mobility and professional development.
Continue reading “Embracing Uncertainty”
Full stack developers are highly sought after in the software engineering world, for good reason. Being able to build a user-facing application while simultaneously keeping APIs, business logic, and databases working together is a valuable and hard to find set of skills.
Equally valuable is the full stack designer. You may not have met one or even heard of them, but they exist and they bring tremendous value to an organization.
A full stack engineer is as comfortable writing a complex SQL query as they are using the Chrome debugger, and a full stack designer knows how to architect the ideal user experience and go beyond the mockup to implement it as an actual user interface.
Continue reading “The Full Stack Designer”
Choosing a technology can be a difficult, stressful, time-consuming process. It’s easy to find yourself in complete analysis paralysis, spending tons of time and money ensuring that your decision is the correct one.
Let’s say you need to choose a database for your new system. Just about every application ever built uses a database, so no matter what you are building this is hardly untrod territory. That means it should be easy to find somebody who has built an application like yours, right? You just need to read their blog about why they picked the tech, mirror their choice, and voila!
Continue reading “How we choose technologies at Corso”
When I worked in the US Department of Defense, our computer systems had password requirements that were the stuff of legend. 3 lowercase letters, 3 uppercase letters, 3 numbers, 4 special characters, and they had to be at least 16 characters long. Plus they had to change every 30 days, and couldn’t be one of the last 25 passwords used. Because these were the requirements for our primary system logins, there was no chance of using a password manager.
So how did people handle this? Everyone diligently memorized the new password every thirty days, thankful that there were policies keeping everything secure, right?
Of course not!
Everybody kept their password on a sticky note stuck to their monitor where it could be viewed by anybody walking past. And the technical people who understood the risks of their password getting compromised? Well, they took a more sophisticated approach like tucking the sticky note in a desk drawer where it would take at least 30 seconds for someone else to find.
Continue reading “Terrible, horrible, no good, very bad password policies”