https://blog.professorbeekums.com/ Recent content on Professor Beekums Blog Hugo -- gohugo.io en-us Mon, 30 Sep 2019 10:09:00 +0000 https://blog.professorbeekums.com/2022/the-value-of-software-estimates/ Sun, 05 Jun 2022 10:09:00 +0000 https://blog.professorbeekums.com/2022/the-value-of-software-estimates/ I’ve written a lot about the challenges of estimates, which may have given the impression that I think they’re useless. They aren’t. Well, not entirely anyway. I think the process of creating estimates is incredibly valuable. Let’s look at all the things we have to think about when creating an estimate: What is the complexity of the work? What are the dependencies for the overall work? What are the dependencies for the specific tasks in the work? https://blog.professorbeekums.com/2022/the-problem-with-software-estimates/ Sun, 08 May 2022 10:09:00 +0000 https://blog.professorbeekums.com/2022/the-problem-with-software-estimates/ I’ve written about the technical challenges of coming up with estimates in software development before. What I’ve neglected to talk about is that one of the biggest problems with getting accurate estimates, particularly for large projects, isn’t technical. The biggest problem is getting to understand your user. Photo by airfocus The idea that you can get accurate estimates for a large project relies on the waterfall model working. You come with some requirements that you know to be excellent. https://blog.professorbeekums.com/2022/march-of-the-agile-consultants/ Sun, 24 Apr 2022 10:09:00 +0000 https://blog.professorbeekums.com/2022/march-of-the-agile-consultants/ Photo by Andrew Neel There was a time where most software was built under the waterfall model. You gathered requirements, then designed your system, then wrote the code, shipped the code to QA, then shipped the code to customers. A nice perfect assembly line. Except software development isn’t an assembly line. When you get a physical product off an assembly line, you can’t just go “oh this would be perfect if we make this small change here in the product. https://blog.professorbeekums.com/2022/users-dont-care-about-jira-board/ Sun, 10 Apr 2022 10:09:00 +0000 https://blog.professorbeekums.com/2022/users-dont-care-about-jira-board/ I’m going to start this off by saying that I think JIRA is an ok tool. Good project management requires some visual tracker on progress. Most people are visual thinkers and while daily standups are great communication tools for getting project status, they are more effective with some visual such as a JIRA board. The problem is when we start to over-value the JIRA board. The problem is when we treat the JIRA board not as a tool, but as an end goal. https://blog.professorbeekums.com/2022/tenacity-makes-great-devs/ Sun, 20 Mar 2022 10:09:00 +0000 https://blog.professorbeekums.com/2022/tenacity-makes-great-devs/ Programmers often joke that our job is mostly copying and pasting stuff from Stack Overflow. If that were true, we wouldn’t be one of the most highly paid professions. And the hiring market wouldn’t be as insane as it is right now. More often than not, the answer is not out there. A developer’s skills are put to the test when they have to implement something no one’s written about or is poorly documented. https://blog.professorbeekums.com/2022/side-projects-make-you-better/ Sun, 06 Mar 2022 10:09:00 +0000 https://blog.professorbeekums.com/2022/side-projects-make-you-better/ In 2014, I had been hearing a lot of talk about Go. It sounded like a really exciting language that I wanted to try. Having learned to code in Java and spending my early career working in Java, I was used to complex inheritence hierarchies and many many layers of abstraction. The notion of NOT having inheritence was so out there. My gut reaction was to dismiss it. Photo by James Harrison https://blog.professorbeekums.com/2022/what-does-a-10x-developer-mean/ Sun, 20 Feb 2022 10:09:00 +0000 https://blog.professorbeekums.com/2022/what-does-a-10x-developer-mean/ I first heard the term “10x developer” a decade ago. My initial reaction to the term was confusion. What does that even mean? That one person types code 10x faster than another person? Or completes 10x more JIRA tickets? Photo by Jon Tyson And if you’re using a descriptor of 10x, who is the base? How are you calculating what someone is being 10x of? At the same time, some developers provide an outsized amount of value and it’s obvious to everyone. https://blog.professorbeekums.com/2022/why-do-developers-hate-meetings/ Sun, 30 Jan 2022 10:09:00 +0000 https://blog.professorbeekums.com/2022/why-do-developers-hate-meetings/ Picture this: you’re a software developer at a small startup. A product manager just handed you some requirements for a new project. The project overall seems pretty simple. Roughly 2 weeks of work for the majority of it. However, hidden in those requirements is a single sentence that calls for concurrency. You’re going to need to coordinate data between multiple users in real time and it has to be accurate. https://blog.professorbeekums.com/2022/developers-need-to-make-mistakes/ Sun, 23 Jan 2022 10:09:00 +0000 https://blog.professorbeekums.com/2022/developers-need-to-make-mistakes/ Think about the last time you learned a skill. Were you awesome at it right off the bat? Or did you make a series of mistakes, learned from each one, and adjusted what you were doing to improve? Photo by Sarah Kilian Anyone being truthful would say the latter. A core part of learning is trying something new to see if it works. Most of the time, it won’t work. That’s ok. https://blog.professorbeekums.com/2022/certifications-dont-prove-competency/ Sun, 16 Jan 2022 10:09:00 +0000 https://blog.professorbeekums.com/2022/certifications-dont-prove-competency/ I’ve written before about how I think college GPAs are a useless metric for hiring managers. It should come as no surprise that I don’t have a very high opinion of certifications either. Photo by unDraw I recently needed to hire an engineer with deep knowledge of AWS. Given the job description saying as much, I received hundreds of applications from folks with a variety of AWS certifications. I ended up interviewing a few dozen of them. https://blog.professorbeekums.com/2022/customer-support-make-better-software/ Sun, 09 Jan 2022 10:09:00 +0000 https://blog.professorbeekums.com/2022/customer-support-make-better-software/ Early in my career, I had the incorrect impression that interacting with customers was beneath me. I had this perception because I was at a large company and standard corporate hierarchies encourage that mentality. Photo by Petr Macháček As a result, it has become a pretty widespread idea in our profession. Even if people don’t say it, they act like it. Later in my career, I was asked in an interview how I would handle relations between support teams and software development teams. https://blog.professorbeekums.com/2021/preventing-hero-culture/ Sun, 02 Jan 2022 10:09:00 +0000 https://blog.professorbeekums.com/2021/preventing-hero-culture/ I’ve written before on the problems of hero culture. It is still my favorite post that I’ve written because it hits so close to home for me. Photo by unDraw Every situation in that post is hypothetical, but based on a real situation I had to deal with myself. Unfortunately, that post is very light on the solution, despite the claim of it being easy. That’s because most of my experience at the time was in the suffering, not in the prevention. https://blog.professorbeekums.com/2021/perils-of-programming-magic/ Sun, 19 Dec 2021 10:09:00 +0000 https://blog.professorbeekums.com/2021/perils-of-programming-magic/ Photo by Artem Maltsev Abstractions are a necessary part of software development. Not having them would make certain things ridiculous. Imagine building an e-commerce store for books and writing code for each title instead of just having code for the concept of “book” and reusing it for all titles. The very concept of a “user” in any application is also an abstraction. We wouldn’t write code for every person that signs up to use our system. https://blog.professorbeekums.com/2021/aws-went-down-now-what/ Sun, 12 Dec 2021 10:09:00 +0000 https://blog.professorbeekums.com/2021/aws-went-down-now-what/ Amazon Web Services went down last Tuesday. It doesn’t happen often, but it is a harrowing experience when it does. Understandably, people get angry during these times. They have come to rely on AWS to provide services necessary for their business. Who isn’t going to be angry when their business stops because of something they can’t control? My day job was certainly impacted as well as my businesses. So what do we do? https://blog.professorbeekums.com/2021/solving-concurrency-problems/ Sun, 05 Dec 2021 10:09:00 +0000 https://blog.professorbeekums.com/2021/solving-concurrency-problems/ Concurrency is a notorious cause of really frustrating bugs. Most software bugs are consistent. If you do X, then Y, then Z, you get Bug A. You can get race conditions with concurrency though. That’s basically a bug where if you do X, then Y, you’ll get Bug A maybe 10% of the time. The occurrence of the bug is intermittent which makes it hard to find the root cause since you can’t reproduce it reliably. https://blog.professorbeekums.com/2021/get-automated-tests-written/ Sun, 21 Nov 2021 10:09:00 +0000 https://blog.professorbeekums.com/2021/get-automated-tests-written/ “It will be easier to get people to write automated tests if we make it easier to write the tests.” I hear this a lot. It seems sensible. It it also ineffective. The key to getting dev teams to write automated tests isn’t reducing friction. Friction isn’t the issue. It doesn’t matter if you can get things to a point where it only takes a few minutes to write tests for a feature that took days to build. https://blog.professorbeekums.com/2021/interview-performance/ Sun, 14 Nov 2021 10:09:00 +0000 https://blog.professorbeekums.com/2021/interview-performance/ This is a conversation I had when I was interviewing a few years ago: Interviewer: “Yeah, a lot of candidates actually have trouble with this problem because it never shows up in the software we write.” Me: “…so why is it part of the interview?” Silence There is so much content out there right now about what candidates can do to “stand out” and “perform” well on interviews. What there isn’t enough of is content for interviewers to conduct better interviews. https://blog.professorbeekums.com/2020/remote-work-is-not-the-best-future/ Wed, 27 May 2020 10:09:00 +0000 https://blog.professorbeekums.com/2020/remote-work-is-not-the-best-future/ There has been quite a bit of talk lately about how companies are moving to remote work. Some people even go so far to say that all companies should be remote. Having an office is just clinging to the past. The office is obsolete and remote work is the future we should have. I can’t disagree more. As far as software development is concerned, I think the most efficient teams in the future will be in the office. https://blog.professorbeekums.com/2019/human-behavior-in-development/ Sun, 01 Dec 2019 10:09:00 +0000 https://blog.professorbeekums.com/2019/human-behavior-in-development/ I find behavioral economics fascinating. Many economists assume rational behavior among all people and it results in economic models that seem good in theory, but end up being completely inaccurate. Humans aren’t 100% rational and the real decisions we make are difficult to account for. We have a similar problem when it comes to the software development process. A lot of it is designed with the assumption that software developers, who are still human, can act in a completely organized and logical fashion with no errors. https://blog.professorbeekums.com/personality-tests/ Mon, 30 Sep 2019 10:09:00 +0000 https://blog.professorbeekums.com/personality-tests/ I find it distressing that more and more companies using personality tests in their interview process. My colleagues mentioned that they have seen this trend increase as well. They note that it is a convenient way to get around anti-discrimination laws because the results are hidden. I’m going to give a benefit of a doubt and not assume this practice is due to some sinister motive. I think a much simpler explanation is that hiring managers are trying to make their jobs easier. https://blog.professorbeekums.com/2019/minimizing-switching-costs/ Tue, 13 Aug 2019 10:09:00 +0000 https://blog.professorbeekums.com/2019/minimizing-switching-costs/ I’ve written previously about the dangers of high switching costs in software development. Being dependant on a third party is a huge risk. You are vulnerable to the whims of another company, including astronomical price increases. However, reliance on vendors is inevitable as they can significantly accelerate product development. Photo by Steve Johnson $500 a month for a third party SAAS sounds like a lot, but it is a lot cheaper than months of in house development. https://blog.professorbeekums.com/2019/accounting-for-inaccurate-estimates/ Mon, 24 Jun 2019 10:09:00 +0000 https://blog.professorbeekums.com/2019/accounting-for-inaccurate-estimates/ Estimates are inevitably going to become inaccurate. There are simply too many factors to take into account to create an accurate estimate in a reasonable manner. As much as we want to try and make our estimates more accurate, a better use of our efforts would be to look at how we handle things when an estimate is missed. Photo by Ugo Mendes Donelli The best way to handle a missed estimate is to find out sooner rather than later. https://blog.professorbeekums.com/randomness-software-estimates/ Mon, 03 Jun 2019 10:09:00 +0000 https://blog.professorbeekums.com/randomness-software-estimates/ Estimates can be useful when building software. There is the immediate comfort in having expectations, but there are also practical benefits. Estimates allow for the proper prioritization of work. We don’t just work on things that are important, we work on things that give us a good amount of value for the time we have to put into them. Photo by Mike Szczepanski Unfortunately, estimates are often inaccurate. The larger the estimate, the larger the margin of error. https://blog.professorbeekums.com/2019/cant-be-a-software-architect-without-code/ Tue, 30 Apr 2019 10:09:00 +0000 https://blog.professorbeekums.com/2019/cant-be-a-software-architect-without-code/ What defines a software architect? It usually means someone has achieved a high level of technical skill. Most of the architects I’ve worked with have been quite good. They may spend a good portion of their day around whiteboards with various teams, but they also spend a decent amount of time writing code. Occasionally, I meet someone who has let the title go to their head. They view writing code as beneath them. https://blog.professorbeekums.com/risky-way-to-account-for-changing-product-req/ Sun, 14 Apr 2019 10:09:00 +0000 https://blog.professorbeekums.com/risky-way-to-account-for-changing-product-req/ All developers have to think about the reality that product requirements change. This is especially true for early products where user research typically needs to last past the first few releases. I’ve started to realize that one way to maintain a lot of flexibility is to minimize logic on the backend and keep things as simple as possible. An example of this would be: let’s say you have a system where your users have lists of things. https://blog.professorbeekums.com/context-in-software-design/ Wed, 27 Mar 2019 10:09:00 +0000 https://blog.professorbeekums.com/context-in-software-design/ Best practices sound like a great thing. Why wouldn’t we want to make sure our software is the best it can be? How better to make it so than to use practices that everyone considers the best? This was something I was extremely concerned with early in my career. I’ve worked in a variety of situations: small companies to large companies, consumer products and B2B products, pure software companies and companies that sold physical things, new software to large mature systems. https://blog.professorbeekums.com/2019/philosophy_technology/ Mon, 11 Mar 2019 10:09:00 +0000 https://blog.professorbeekums.com/2019/philosophy_technology/ A lot of factors are considered in a build vs buy decision. What are the technical capabilities of existing systems? Is the functionality a core offering of my own product? How complex would it really be to build? How much would buying cost? What about switching costs? One thing I find myself considering more and more is the philosophy of the people who are building the technology I am evaluating. This isn’t something I normally list out out explicitly, and it is rarely brought up in discussions with other developers. https://blog.professorbeekums.com/2019/failing-fast-not-enough/ Sun, 17 Feb 2019 10:09:00 +0000 https://blog.professorbeekums.com/2019/failing-fast-not-enough/ Failing fast has become a common trope by now. It makes a lot of sense in some contexts. Fear of failing causes many problems, the biggest of which is being afraid to try something new. Even if a new thing only has a 1% chance of teaching you something useful, not trying gives you a 0% chance of learning something useful. Fear of failing prevents long term success. Overcoming this fear isn’t easy, but it can be done. https://blog.professorbeekums.com/why-are-tests-not-written/ Sun, 03 Feb 2019 10:09:00 +0000 https://blog.professorbeekums.com/why-are-tests-not-written/ It is hard to argue against writing tests. They save a huge amount of time relative to the how much effort it takes to write them. The increased quality of the product also makes a good impression with users. Yet all too often, tests are not written. Even for advocates of automated testing like myself, there’s either a temptation to skip writing tests “just this once” or “this feature doesn’t need tests”. https://blog.professorbeekums.com/user-experience-programming-languages/ Mon, 21 Jan 2019 10:09:00 +0000 https://blog.professorbeekums.com/user-experience-programming-languages/ When we talk about UX, we often refer to the UX of the products we build and use. We want our products to be easy to use. Interactions should be quick. Mistakes should be easy to recover from. These things are also good to have in the tools we use to build software, especially programming languages. I’ve worked in a fair number of languages: Java for almost 15 years, PHP for 8, Javascript for 8, and dabbled in a few others like C# and Go. https://blog.professorbeekums.com/ai-writing-code/ Sun, 06 Jan 2019 10:09:00 +0000 https://blog.professorbeekums.com/ai-writing-code/ I’m pretty skeptical of AI replacing humans anytime soon, but there is no denying that AI is capable of things that humans aren’t. Computers are unmatched in their ability to run brute force calculations. Theoretically, a human could perform Google’s PageRank algorithm. Yet, it would take a human millions of times more time than a computer to do so and the monotony would result in human error. Garry Kasparov mentioned that chess engines are superior to humans in short term tactical positions and the only way to beat them is to avoid positions that are conducive to those types of tactics. https://blog.professorbeekums.com/need-date-time-picker/ Tue, 04 Dec 2018 09:09:00 +0000 https://blog.professorbeekums.com/need-date-time-picker/ I recently came across the need for a date/time parser that used natural language processing. Maleega’s date picker is extremely barebones and needed replacing. I left it barebones because I wanted time to figure out how to build a good date/time picker. Every one that I’ve used has felt clunky. This is probably because of the inherent challenges with date and time. There’s a lot of complexity in time that we don’t think about because we’ve learned to talk about time from a very young age. https://blog.professorbeekums.com/the-right-time-for-abstractions/ Mon, 26 Nov 2018 09:09:00 +0000 https://blog.professorbeekums.com/the-right-time-for-abstractions/ Abstractions are a critical part of software development. While we developers often abstract too much, software would take exponentially more time to build today without abstractions. Few write their own code to store data these days. We use databases instead. The same goes for web servers. And HTTP libraries. And JSON encoders/decoders. Like anything though, we can have too much of a good thing. The point where we’ve over used abstractions usually involves the business logic of a product. https://blog.professorbeekums.com/the-wonder-of-human-intelligence/ Thu, 08 Nov 2018 11:09:00 +0000 https://blog.professorbeekums.com/the-wonder-of-human-intelligence/ There’s a lot of fear about AI replacing us humans, much of it around jobs specifically. History is filled with examples of jobs being lost to automation in general. While there was some suffering, society overall improved. Would you prefer to live in a world where a human has to operate an elevator for you? How many of you remember the long lines in the cash lane at toll booths? Roads will be safer when drivers no longer get drunk or sleepy. https://blog.professorbeekums.com/role-manual-testing/ Tue, 23 Oct 2018 17:09:00 +0000 https://blog.professorbeekums.com/role-manual-testing/ I’m a big fan of automated testing. The math just works out. Why spend hours running a series of test cases when a computer can do it in seconds. With benefits like this, my zeal for automated testing can make it seem like I think that all testing should be automated. However, this couldn’t be farther from the truth. There is little room in software development for pure rote manual testing, but that’s not the only reason to manually test software. https://blog.professorbeekums.com/what-is-money/ Wed, 19 Sep 2018 17:09:00 +0000 https://blog.professorbeekums.com/what-is-money/ Cryptocurrencies have had a lot of ups and downs. A lot of questions have been asked about whether they’re actually viable or not. These conversations have been focused on the technical problems such as slow transactions, preventing the 51% attack, bugs in smart contracts, etc. Yet, solving technical problems won’t have as much of an effect as other factors. To understand those other factors, we need to start thinking about what money is. https://blog.professorbeekums.com/abstraction-for-the-sake-of-abstraction/ Tue, 04 Sep 2018 10:09:00 +0000 https://blog.professorbeekums.com/abstraction-for-the-sake-of-abstraction/ There’s something deeply ingrained in many developers, including myself, that creates a tendency to over-engineer. Maybe it’s how we’re taught or maybe it’s a natural desire to “future proof” our code. Regardless, this tendency is so strong that even being aware of it is not enough to prevent the behavior. Earlier this year, I was working on a system for helping users filter their emails. While I love Gmail filters, the experience of creating them and debugging them is a bit lacking. https://blog.professorbeekums.com/who-tests-code/ Sun, 19 Aug 2018 17:09:00 +0000 https://blog.professorbeekums.com/who-tests-code/ Who writes code? The obvious answer is that developers write code. Who makes sure the code works? The answer to this question also seems obvious. It should also be developers… right? Fairly often, that is not actually the case. Many companies have separate QA departments that are responsible for making sure code works. Developers write code, then they throw it over a wall for someone else to test for them. https://blog.professorbeekums.com/backfilling-tests/ Sun, 05 Aug 2018 17:09:00 +0000 https://blog.professorbeekums.com/backfilling-tests/ Automated testing is a wonderful thing. Think about it. Why spend hours, or even a few minutes, doing something that takes a computer less than a second. I’ve never regretted writing tests, especially after seeing the time to debug and fix bugs in a subsystem go from hours to minutes. Bug report -> investigation -> code fix -> test -> release, can all be done in under 15 minutes when automated tests are around. https://blog.professorbeekums.com/constructive-procrastination/ Sun, 15 Jul 2018 17:09:00 +0000 https://blog.professorbeekums.com/constructive-procrastination/ I recently read a great article about procrastination. While the common viewpoint is that procrastination is a waste of time, it can also be a source of creativity. It reminds me of the classic advice when banging your head against a problem: take a break. Step away. Breathe. A year ago I started taking this advice a little further. If I am stuck with a problem, I put it off for at least a day. https://blog.professorbeekums.com/things-that-dont-matter/ Sun, 17 Jun 2018 17:09:00 +0000 https://blog.professorbeekums.com/things-that-dont-matter/ I like to joke that one day I’m going to get a Phd in economics and make my thesis the cost to global GDP of the tabs vs spaces debate. There’s a great episode of Silicon Valley about it. Unfortunately, while the show does exaggerate some things for comedic effect, the brilliance of that show is how close it hits to home. For those who don’t know what the debate is about, developers can indent their code with spaces where it will look like this: Or they can indent their code where it will look like this: Can you spot the difference? https://blog.professorbeekums.com/multitasking/ Tue, 22 May 2018 17:09:00 +0000 https://blog.professorbeekums.com/multitasking/ Multi-tasking doesn’t exist. All the science tells us that we are only capable of task switching. And task switching is really bad for us. Every time we switch tasks, we add to our cognitive load making us less effective at all the tasks we are attempting to do at once. A lot has been written on this topic with the attempt to justify creating work environments where people can focus. https://blog.professorbeekums.com/password-rules/ Sun, 29 Apr 2018 17:09:00 +0000 https://blog.professorbeekums.com/password-rules/ Passwords play a big role in protecting our data. Either a service provides a way to login with a password, or they provide a way to login with another service like email, Google, or Twitter and those services use passwords. Passwords are unavoidable and important. That means the passwords themselves need to be secure. Many services have password rules to ensure that people create secure passwords. A lot has been written on password rules. https://blog.professorbeekums.com/managing-unknowns/ Sun, 15 Apr 2018 17:09:00 +0000 https://blog.professorbeekums.com/managing-unknowns/ Software development is notoriously difficult to estimate. For this reason, I know few people who take the Waterfall process seriously. There are many factors that create a level of unpredictability. One is that there are usually pieces that need to be built that a developer has never built before. The lack of domain experience will result in something being missed and all the planning in the world won’t catch everything. Is it worthwhile to restrict ourselves to only building things we’ve built before? https://blog.professorbeekums.com/interview-actual-skillset/ Sun, 25 Mar 2018 17:09:00 +0000 https://blog.professorbeekums.com/interview-actual-skillset/ Hiring software developers is a difficult endeavor. Good developers are hard to source and they’re hard to interview. I have zero advice on the former, but plenty of experience with the latter. When I first started interviewing developers, I had no idea where to start. The only advice I received was “Try to determine if you would like to work with the person.” How do I find out if I would like to work with someone after an hour or two? https://blog.professorbeekums.com/i-dont-want-to-maintain-their-code/ Sun, 25 Feb 2018 20:26:00 +0000 https://blog.professorbeekums.com/i-dont-want-to-maintain-their-code/ I recently heard of a situation where a team needs to hire someone since they’re understaffed. The reaction from one of the developers was simply: “I don’t want to maintain their code.” I understand this mentality. The worst code is always other people’s code. For most developers, this is simply fact. What is also fact is that very little software of significance gets built by the lone wolf. Building software is a difficult endeavour. https://blog.professorbeekums.com/build-for-resilience/ Mon, 12 Feb 2018 20:26:00 +0000 https://blog.professorbeekums.com/build-for-resilience/ All software systems will fail. This is unfortunately a fact of life. Not even the biggest companies talk about 100% uptime. They talk about the number of ‘9’s of uptime a system has (e.g. 3 9s is 99.9% and 5 9s is 99.999%). Being able to claim a large number of 9s is a point of pride. While all software fails, developers can show off their skills by claiming to have a large number of 9s. https://blog.professorbeekums.com/how-developers-make-their-job-harder/ Sun, 28 Jan 2018 20:26:00 +0000 https://blog.professorbeekums.com/how-developers-make-their-job-harder/ Software development is hard. Bugs and inaccurate time estimates are a fact of life. Software is too complex these days for things to go exactly as we’d like. However, developers often add to the difficulty of software development by doing certain things that make it harder than necessary. I know I have. One of these tendencies is associating less typing with saving time. It sounds logical at first. Type less code, spend less time writing code. https://blog.professorbeekums.com/value-of-experience/ Sun, 14 Jan 2018 20:26:00 +0000 https://blog.professorbeekums.com/value-of-experience/ I often say that one of my favorite quotes is: “There are developers with 30 years of experience and there are developers with 1 year of experience repeated 30 times.” This was said by a professor of mine who had 30 years of experience. It’s an important thought because some developers may have a lot of experience on paper, but they aren’t actually very good developers. They stopped learning early on which means they operate at a junior level despite the number of years they have been developing software. https://blog.professorbeekums.com/project-management-hoarding/ Sun, 31 Dec 2017 20:26:00 +0000 https://blog.professorbeekums.com/project-management-hoarding/ Regardless of what project management software you use, be it JIRA, Asana, Trello, or whatnot, one thing is true for all of them: adding new tasks is really easy. Finishing things requires actually doing the work or coming up with an extremely compelling reason to delete a task. The notion of tasks being easy to create and hard to remove will naturally result in many tasks piling up. There are good reasons for this. https://blog.professorbeekums.com/short-term-benefits-unit-tests/ Sun, 10 Dec 2017 20:26:00 +0000 https://blog.professorbeekums.com/short-term-benefits-unit-tests/ Many developers have one of two opinions about unit tests: they believe 100% of the code has to be covered by unit tests, or they believe 100% of the code has to be covered by unit tests but they have reasons for not writing any. It isn’t common to find people who dislike the idea of unit tests. The main cost of having unit tests is spending time to write them. https://blog.professorbeekums.com/taking-on-technical-debt/ Sat, 25 Nov 2017 17:09:00 +0000 https://blog.professorbeekums.com/taking-on-technical-debt/ Technical debt is a contentious topic. Building product quickly is at first a very desirable goal, but oftentimes that means taking on technical debt which can slow down a team’s ability to build product in the future. Figuring out the right balance between building quickly in the short term vs building quickly in the long term is quite challenging. The basic principle is a simple ROI calculation. With financial debt, you take it when you believe the money you can make with that debt exceeds the cost you pay in interest. https://blog.professorbeekums.com/story-point-and-time/ Sun, 05 Nov 2017 20:26:00 +0000 https://blog.professorbeekums.com/story-point-and-time/ One of the first things used to describe story points is a negative: story points do not equal time. 1 story point can not be equated with 1 hour, 3 hours, or any other unit of time. While it can be advantageous to have a unit of work that isn’t associated with time, it is important to note that story points will ultimately be a unit of time. Story points are used in conjunction with sprints. https://blog.professorbeekums.com/front-end-architecture/ Sun, 22 Oct 2017 20:26:00 +0000 https://blog.professorbeekums.com/front-end-architecture/ Early in September I decided that I was going to rebuild the front end of my new product. Part of why I made this decision was because I had built my alpha with the intention of rebuilding it. A lot of that decision was because of what I wanted to do with my content pages. I personally dislike most home and content pages. They have a lot of content, but end up saying very little about what the product actually does. https://blog.professorbeekums.com/letting-go-of-the-edge-cases/ Sun, 08 Oct 2017 20:26:00 +0000 https://blog.professorbeekums.com/letting-go-of-the-edge-cases/ Someone once mentioned that he enjoys reading my articles because they are to the point. The reason for that is because I often leave out edge cases. I will make statements such as “X is true” rather than “X is true, except for A, B, C, D, and E. Also F in cases of G.” The reason isn’t because the edge cases aren’t important. The reason is that they aren’t always necessary. https://blog.professorbeekums.com/aspects-of-a-developer/ Sun, 24 Sep 2017 20:26:00 +0000 https://blog.professorbeekums.com/aspects-of-a-developer/ I try to be better tomorrow than I am today. I am constantly thinking about what my strengths are and what I’m weak at. It is impossible to be good at everything though. That means needing to be selective with how I spend my time on improving. What will give me the most value for my time? This thought process is more than for just personal growth too. Knowing what different skillsets are available and being able to identify them in others is critical when hiring developers. https://blog.professorbeekums.com/time-estimate-tradeoffs/ Sun, 10 Sep 2017 20:26:00 +0000 https://blog.professorbeekums.com/time-estimate-tradeoffs/ I like time estimates when building software. This isn’t a popular opinion, but time estimates have some valuable uses so long as they aren’t abused. Time is the most valuable resource anyone or any company has. I like making sure my time is spent well. I want the greatest return possible on any of my time investments. In software this means working on the features that provide the most value for the time spent. https://blog.professorbeekums.com/performance-vs-scalability/ Sat, 19 Aug 2017 20:26:00 +0000 https://blog.professorbeekums.com/performance-vs-scalability/ One thing that tripped me up early on in my career was the difference between performance and scalability. At first I thought they were exactly the same. I was quite surprised when my first project to scale a system actually made my code run slower… in my dev environment at least. Let’s get definitions out of the way. Scalability is being able to handle large amounts of users/data/traffic. Performance is about speed. https://blog.professorbeekums.com/team-of-teams/ Sun, 13 Aug 2017 20:26:00 +0000 https://blog.professorbeekums.com/team-of-teams/ I just finished Team of Teams and it is one of my favorite books now. I’ve written about the most effective dev team I’ve been in before, but it came with the caveat that I had not seen that kind of structure scale up. Team of Teams describes a similar structure… scaled up to the size of all US forces in Afghanistan. While there are significant differences between technology companies and the military, the one important similarity is that both are composed of people. https://blog.professorbeekums.com/technology-problems-are-people-problems-first/ Sun, 06 Aug 2017 20:26:00 +0000 https://blog.professorbeekums.com/technology-problems-are-people-problems-first/ I’m a software developer. When I see a technical problem, my first thoughts are always for technical solutions. It is the obvious thing to do. However, solving a problem well often requires understanding what caused the problem in the first place. “The previous developer is so bad and I am so baller” was often the answer when I was a lot younger. That specific answer is often incorrect. However, it does bring up the point that technical problems don’t just appear. https://blog.professorbeekums.com/all-code-is-debt/ Sun, 30 Jul 2017 20:26:00 +0000 https://blog.professorbeekums.com/all-code-is-debt/ Developers often try to minimize the amount of technical debt they take on when building software. Many will even try to have “zero” technical debt. It sounds like a worthwhile goal. Technical debt can be extremely costly in the long term so getting rid of it can be extremely advantageous down the line. It isn’t possible to have zero technical debt though. That’s because all code is technical debt. Every single line of it. https://blog.professorbeekums.com/do-you-need-the-best/ Sun, 23 Jul 2017 20:26:00 +0000 https://blog.professorbeekums.com/do-you-need-the-best/ Lots of people talk about wanting to hire the best developers. The reasoning is sound. A good developer is often said to be 10x-100x better than a mediocre developer. In many cases that’s true. I want to go into the cases where this hiring policy doesn’t make sense though. The first problem with this policy uses some basic math. Only 10% of people can be in the top 10%. Only 1% of people can be in the top 1%. https://blog.professorbeekums.com/process-no-substitute/ Sun, 16 Jul 2017 20:26:00 +0000 https://blog.professorbeekums.com/process-no-substitute/ I love software process. My passion is finding ways to build software faster, but better technology is only half the battle. The other half is a people and organization problem. Process can do wonders for that half. Among some of the benefits process can bring to a project are: Ensuring everyone is working on the most important thing Coordinating efforts to distribute work effectively Adding little nudges to improve code quality such as automated testing and code reviews That last bit is where process can become a disaster though. https://blog.professorbeekums.com/when-is-the-job-done/ Sun, 09 Jul 2017 20:26:00 +0000 https://blog.professorbeekums.com/when-is-the-job-done/ This may sound like a silly question. “When is a developer’s job done?” It seems obvious at first. Developers write code. Their job is done when code is written. I used to have this view. My first job out of college had 3 month code freezes before each release. That 3 months was for the QA team to fully test things. The code I wrote was often tested weeks after I wrote it. https://blog.professorbeekums.com/limitations-tech/ Sun, 02 Jul 2017 20:26:00 +0000 https://blog.professorbeekums.com/limitations-tech/ Whenever I evaluate tech, all I usually see are the great things about it. It doesn’t matter if it is a database, a web framework, a programming language, a library, etc. Those who talk about tech tend to be either fans of it or the creators of that technology. It is in their best interests to get people to use it. Emphasizing the positive aspects of a piece of technology helps do that. https://blog.professorbeekums.com/death-marches/ Sun, 25 Jun 2017 20:26:00 +0000 https://blog.professorbeekums.com/death-marches/ Imagine you’re a manager on a large software project. You’ve got about a month to go before the intended deadline and your team appears to need at least 3 more months before being done. What do you do? Many come under the temptation to start a so called “death march”. It essentially means having folks work as many hours as possible: nights, weekends, whenever. After all, if a developer can get a certain amount of work done in 40 hours a week, then they should be able to get three times as much done in 120 hours a week right? https://blog.professorbeekums.com/worst-bugs/ Sun, 18 Jun 2017 20:26:00 +0000 https://blog.professorbeekums.com/worst-bugs/ I’ve talked briefly before about developers suffering from “it works on my machine” mentality. The result is bugs that don’t appear on a developer’s machine, but do appear for users. There is a worse class of bugs though that affects everyone at a company: “it works in my office when I’m trying it” How is this different? Things can get pretty complex in a live web application. The vast number of variables involved mean it is perfectly possible for users to see bugs that no one at the company can reproduce. https://blog.professorbeekums.com/thousand-cuts/ Sun, 11 Jun 2017 20:26:00 +0000 https://blog.professorbeekums.com/thousand-cuts/ Trying to meet deadlines on a software project is extremely challenging. Estimating software is inherently difficult because writing code is not like working on an assembly line. It’s more like writing a book. You can rush writing a book, but you pay the cost of continuity issues, poor grammar, half baked plots, and undeveloped characters. In software all of those thing manifest in the form of bugs or a product that just doesn’t work. https://blog.professorbeekums.com/not-everything-needs-to-scale/ Sun, 04 Jun 2017 20:26:00 +0000 https://blog.professorbeekums.com/not-everything-needs-to-scale/ Not every feature needs to scale. It’s a little ironic to have those words coming from me since I’ve spent most of my time making applications scale. My time was spent that way because making sure popular features can handle being used by millions of users is important. Without scaling, the application will crash. Those users will be unable to use the product. All the effort spent in acquiring those users will be wasted. https://blog.professorbeekums.com/accuracy-vs-clarity/ Sun, 28 May 2017 20:26:00 +0000 https://blog.professorbeekums.com/accuracy-vs-clarity/ It often feels like accuracy should be the most important thing when conveying information. Why wouldn’t it be? What’s the point of explaining something that’s false? Whether we are writing a blog post, documentation, a book, or anything that someone else will read, we want to make sure what we are saying is true. But being 100% accurate is not always the most important thing. I would argue that settling for 80-90% accuracy can be ok if it helps make things significantly clearer. https://blog.professorbeekums.com/mentoring/ Sun, 21 May 2017 20:26:00 +0000 https://blog.professorbeekums.com/mentoring/ Mentoring is one of my favorite activities. No reasonably complex system can be built by a single developer. It takes a team. Helping other members of the team reduces my own workload in the long run, even if it increases it in the short term. Eventually, I found myself enjoying the activity for the sake of it and not just to reduce my own workload. I started treating it as a skill on its own that needed to be improved. https://blog.professorbeekums.com/building-no-features-2/ Sat, 13 May 2017 20:26:00 +0000 https://blog.professorbeekums.com/building-no-features-2/ This is a continuation of the last post on the challenges a hypothetical startup starts seeing as it starts gaining more and more users. We left off having solved the problems of an overloaded web server and putting images in an appropriate storage solution. Unfortunately, the startup’s problems have just gotten started. While the startup may have fixed things for users, a costly side effect has been introduced. Developers tend to write code on a single computer. https://blog.professorbeekums.com/building-no-features-1/ Sun, 07 May 2017 20:26:00 +0000 https://blog.professorbeekums.com/building-no-features-1/ Small startups tend to build features very quickly. Often times it is a lot quicker than bigger companies even though bigger companies have more resources. The easy answer to why this happens is that big companies have a lot of bureaucracy that slows them down. There’s a lot more to it than that though. The bigger company is also going to have many many more users. This single difference adds a significant amount of work the bigger company has to do to build the same feature as a smaller one. https://blog.professorbeekums.com/data-modeling-product-managers/ Sun, 30 Apr 2017 17:09:00 +0000 https://blog.professorbeekums.com/data-modeling-product-managers/ Data modeling has a prominent place in the course on high level software development fundamentals. There’s a big chunk of the introductory lesson devoted to it. The second lesson is devoted to it. A future lesson is planned on it. I will also be creating a full course on it at some point. It’s given such prominence because of how important it is in software development. It isn’t just for developers either. https://blog.professorbeekums.com/take-time-to-explain/ Sun, 23 Apr 2017 17:09:00 +0000 https://blog.professorbeekums.com/take-time-to-explain/ There is this great article about how Kotaku made a post about clever tricks used by game developers and how a number of developers criticized it. Why bother making a post explaining something so basic? Who cares? Apparently lots of people did. What one person considers basic is actually quite clever and interesting to another. Why would anyone want to mock a person’s curiosity? Everyone starts off not knowing much and getting that knowledge usually requires having someone willing to explain. https://blog.professorbeekums.com/heroes-in-software-development/ Sun, 16 Apr 2017 17:09:00 +0000 https://blog.professorbeekums.com/heroes-in-software-development/ Imagine your web application goes down in the middle of the night. It’s 2 AM, but your business is global. You have users in every time zone. They’re angry. They’re unable to purchase things on your website or are canceling their subscriptions. Money is being lost every minute your web application is down. Suddenly, one of your developers is on the case! This developer shows a little anxiety and curses a lot (it is 2 AM after all), but eventually the problems are resolved. https://blog.professorbeekums.com/why-i-dont-prepare-for-interviews/ Sun, 09 Apr 2017 17:09:00 +0000 https://blog.professorbeekums.com/why-i-dont-prepare-for-interviews/ As a candidate, I have only worked with an external recruiter once. I found it interesting that they told me almost the exact questions to expect during my interviews. After the interview, they asked me what questions I had to answer. I assume this was to improve their data for future candidates. I’ve been told that this is both common and considered a good thing. Candidates who have a chance to prepare for the interview are more likely to succeed. https://blog.professorbeekums.com/dont-outsource-maintenance/ Sun, 02 Apr 2017 17:09:00 +0000 https://blog.professorbeekums.com/dont-outsource-maintenance/ A friend once told me that they work at a company where the maintenance of software is outsourced. That means their in house developers only work on new features. Bugs and such are handled by an outsourced team. I can only guess as to why this company chose to do this. Maybe they think it’s more efficient. Maybe their developers just refused to do maintenance. Regardless, I was horrified. This is one of the worst practices used to manage software projects. https://blog.professorbeekums.com/build-vs-buy-decisions/ Sun, 26 Mar 2017 17:09:00 +0000 https://blog.professorbeekums.com/build-vs-buy-decisions/ A developer’s job isn’t exclusively writing code. The job is to build systems that bring value to the business. Often times that means choosing to use software written by third parties instead of writing the code from scratch. Whether the option is to purchase a proprietary solution or using an open source one, the situation is the same: the software you are building is now reliant on a third party. For this reason, building your own software has a number of advantages. https://blog.professorbeekums.com/job-hopping/ Sun, 19 Mar 2017 17:09:00 +0000 https://blog.professorbeekums.com/job-hopping/ Job hopping is not considered an admirable trait, at least by employers. There is not much for them to like about a developer that leaves after a short tenure. Hiring people is an expensive process since it requires the expense of recruiters as well as time spent by the existing development team for interviews. Time spent in interviews is time that could be spent building software. This makes a developer with wanderlust extremely costly for a company. https://blog.professorbeekums.com/interviews-should-be-based-on-job-needs/ Sun, 12 Mar 2017 17:09:00 +0000 https://blog.professorbeekums.com/interviews-should-be-based-on-job-needs/ I’ve written about performing interviews for developers. There is way too much focus on developers improving their “interviewing skills” and not enough on interviewers doing a better job themselves. One of the problems interviewers have is they ask candidates to solve classic computer science problems. I did this when i first started interviewing. It made sense because it was what everyone else did. Also if a person’s job is to write software, they should be good at algorithms! https://blog.professorbeekums.com/software-systems-will-fail/ Sun, 05 Mar 2017 17:09:00 +0000 https://blog.professorbeekums.com/software-systems-will-fail/ Gitlab had a very public outage last month. Most companies provide some kind of explanation when their services are interrupted. Those are usually sanitized (or seem sanitized) to make things seem better than they actually are. Gitlab instead provided an extremely detailed report of the incident as well as all the things they know they could be better at. Some of my friends were extremely troubled by the report. They believed that Gitlab has shown extreme incompetence and can’t be trusted by their customers. https://blog.professorbeekums.com/estimating-software-bugs/ Sat, 25 Feb 2017 17:09:00 +0000 https://blog.professorbeekums.com/estimating-software-bugs/ Software bugs are an inevitable part of any complex application. The human mind may be able to understand how an application works at a high level, but being able to have every detail floating around in your head is impossible. That means that it is very easy for a programmer to miss handling a specific situation in their code, aka edge cases, because they aren’t thinking about it. The result is unintended behaviour in that software or a software bug. https://blog.professorbeekums.com/you-cant-learn-everything/ Sat, 18 Feb 2017 17:09:00 +0000 https://blog.professorbeekums.com/you-cant-learn-everything/ There is a lot to learn about software development. I’ve heard many jokes about how many front end frameworks there are. Back end frameworks are joked about less often, but they’re just as numerous. Every month I also hear about a new programming language that I simply must try because it will solve all my problems. There’s also a know it all blogger out there who thinks every developer should also have sysadmin experience. https://blog.professorbeekums.com/learning-to-make-maintainable-code/ Sun, 12 Feb 2017 23:14:00 +0000 https://blog.professorbeekums.com/learning-to-make-maintainable-code/ Programmers want to write good code. It makes sense. Folks in every profession take pride in their work and want to make sure it is of the highest quality. High quality software includes many things, one of which is making code easy to modify/maintainable. Software is never really “done”. There are always new versions with new features which obviously means that there is more code written. That code is usually written on top of existing features. https://blog.professorbeekums.com/2017/02/my-most-valuable-developer-experience.html Sun, 05 Feb 2017 23:38:00 +0000 https://blog.professorbeekums.com/2017/02/my-most-valuable-developer-experience.html I’ve been a developer for over a decade now. Those years were filled with valuable experiences that were essential in making me a better developer today than I was. There was one experience in particular that was key in improving my thinking about software development. I once took a job a small company as the only back end developer other than the CTO. Like many small companies, I also doubled up as a sysadmin… only I had very minimal sysadmin experience. https://blog.professorbeekums.com/2017/01/the-most-effective-software-development.html Sun, 29 Jan 2017 23:14:00 +0000 https://blog.professorbeekums.com/2017/01/the-most-effective-software-development.html I think a lot about how teams should be structured when building software. Many companies choose to distinguish their teams by discipline. There is the Development team. The UX team. The Product team. The QA team. The Support team. The Marketing team. It makes sense at first. The manager for folks in a given discipline should have experience performing the job in that discipline. You wouldn’t want a developer managing UX designers and vice versa. https://blog.professorbeekums.com/2017/01/how-do-you-know-developer-is-doing-good.html Sun, 22 Jan 2017 23:11:00 +0000 https://blog.professorbeekums.com/2017/01/how-do-you-know-developer-is-doing-good.html Evaluation of developers is an important topic for anyone involved in software development. Many developers care a great deal about career growth or raises at the very least. Managers need to be able to justify decisions around promotions and raises. Ideally, developers would be rewarded based on the amount of value they provide to a business. It’s a simple concept: you make the company more money, the company pays you more money. https://blog.professorbeekums.com/2017/01/do-programming-languages-matter.html Sat, 14 Jan 2017 23:06:00 +0000 https://blog.professorbeekums.com/2017/01/do-programming-languages-matter.html A lot of attention is given to programming languages. Many companies list positions such as “PHP Developer” or “Java Programmer”. Those interested in learning how to code often ask what language they should learn. Developers themselves argue over the merits of various languages. Does it really matter what programming languages you know though? There are a growing number of people, including myself, that don’t take known languages into account when hiring. https://blog.professorbeekums.com/2017/01/software-developers-should-have.html Sun, 08 Jan 2017 23:26:00 +0000 https://blog.professorbeekums.com/2017/01/software-developers-should-have.html Being​ ​a​ ​software​ ​developer​ ​and​ ​being​ ​a​ ​system​ ​administrator​ ​are​ ​very​ ​different​ ​things.​ ​Many folks​ ​lump​ ​the​ ​two​ ​professions​ ​together,​ ​but​ ​the​ ​skillsets​ ​do​ ​not​ ​overlap​ ​much.​ ​Software developers​ ​write​ ​code.​ ​System​ ​administrators​ ​maintain​ ​the​ ​computer​ ​systems​ ​that​ ​the​ ​code runs​ ​on. Both​ ​are​ ​critical.​ ​Software​ ​provides​ ​value​ ​to​ ​users​ ​such​ ​as​ ​yourself,​ ​but​ ​software​ ​can’t​ ​exist without​ ​an environment​ ​to​ ​run​ ​on. Many companies like to keep developers and sysadmins on separate teams. https://blog.professorbeekums.com/2017/01/follow-up-on-what-makes-senior-software.html Sun, 01 Jan 2017 22:07:00 +0000 https://blog.professorbeekums.com/2017/01/follow-up-on-what-makes-senior-software.html A few readers asked me to do a follow up with the responses people sent in for what they thought made a developer a senior developer. I compiled all the emails I received with the comments on Hacker News. Many folks had their own version of the checklist with different items on their respective lists. I found one to be very interesting though. I was sent a link to a post on this exact topic by Frontside. https://blog.professorbeekums.com/2016/12/follow-up-on-beware-of-developers-who.html Sun, 25 Dec 2016 20:26:00 +0000 https://blog.professorbeekums.com/2016/12/follow-up-on-beware-of-developers-who.html The post on “Beware of Developers Who Do Negative Work” was both enjoyed by many and highly criticized by many. I’m usually fine with criticism, but one point really stung. A lot of the criticism denounced the idea that junior developers do negative work. They need mentoring and coaching, not to be frightened and have their insecurities targeted by callous bloggers such as myself. The point stung for two reasons. https://blog.professorbeekums.com/2016/12/beware-of-developers-who-do-negative.html Sun, 18 Dec 2016 20:51:00 +0000 https://blog.professorbeekums.com/2016/12/beware-of-developers-who-do-negative.html UPDATE 2016-12-25: This post has an important follow-up. At some point in every software developer’s career, we work with someone who does negative work. The notion of negative work may sound a little strange. Someone can do no work by just… not working. How does negative work happen? One example of this is an awful developer that was once at the same company as me. He made 2 changes to the code base over his 6-month tenure there. https://blog.professorbeekums.com/2016/12/what-makes-senior-software-developer.html Sun, 11 Dec 2016 20:25:00 +0000 https://blog.professorbeekums.com/2016/12/what-makes-senior-software-developer.html UPDATE 2017-01-01: This post has a follow up. Most engineering organizations will have to answer the question: “What makes a software developer a senior developer?” This is a challenging question because it is extremely subjective. Search for the answer on the internet and you will get many different answers. Some will contain criteria that are also subjective themselves which adds additional difficulty to the question. What makes the question even harder to answer is that some companies don’t really care. https://blog.professorbeekums.com/2016/12/should-you-hire-bootcamp-graduate.html Sun, 04 Dec 2016 23:27:00 +0000 https://blog.professorbeekums.com/2016/12/should-you-hire-bootcamp-graduate.html Developer/coding bootcamps are incredibly popular right now. That should not be a surprise to anyone. Software development is an incredibly lucrative field. There is a much greater demand for talent than there is supply. I’ve seen that from both the hiring side and the job applicant side. It makes sense that a lot of folks out there are interested in becoming software developers. Bootcamps are there to help fill the demand for that education. https://blog.professorbeekums.com/2016/11/code-reviews-are-awesome-sometimes.html Sun, 27 Nov 2016 20:32:00 +0000 https://blog.professorbeekums.com/2016/11/code-reviews-are-awesome-sometimes.html Code reviews are seen as an essential part of software development. It makes a lot of sense to say that a programmer should have their work reviewed by another programmer. Authors and journalists have their work reviewed by an editor after all. Humans make mistakes and creators especially get a little tunnel vision when they are focused on making their creations. Having someone else look at it can catch many errors. https://blog.professorbeekums.com/2016/11/programming-has-changed-my-life.html Sat, 19 Nov 2016 17:42:00 +0000 https://blog.professorbeekums.com/2016/11/programming-has-changed-my-life.html Sometimes I look back on my life and wonder what it would have been like if I had never started programming. Obviously my career would be different, but I believe that programming has fundamentally changed how I think. Who I am as a person has changed significantly due to solving as many software problems as I have and the changes have been for the better. Teenage me was severely flawed. https://blog.professorbeekums.com/2016/11/balancing-desire-to-under-engineer-and.html Sun, 13 Nov 2016 20:04:00 +0000 https://blog.professorbeekums.com/2016/11/balancing-desire-to-under-engineer-and.html Software development is a balancing act of spending too little time planning out a project and spending too much time. If we under-engineer the project by not planning enough, then we will end up with lots of technical debt. The result will be lots of time wasted dealing with that technical debt. Think of it as building a house with a really shaky foundation. You end up spending more trying to fix things than it would have cost doing things properly the first time. https://blog.professorbeekums.com/2016/11/hiring-software-developers-when-you-are.html Fri, 04 Nov 2016 20:13:00 +0000 https://blog.professorbeekums.com/2016/11/hiring-software-developers-when-you-are.html Hiring software developers is hard. It’s hard when you are a software developer and have intimate knowledge of the skillset required. It is even harder when you don’t have that skillset. I’ve met many entrepreneurs who are in the latter situation. How do these folks go about hiring developers for contract or full time? Many try by just talking to a developer. At that point you’re effectively just listening to a sales pitch. https://blog.professorbeekums.com/2016/10/short-term-goals-and-long-term-goals.html Thu, 27 Oct 2016 20:36:00 +0000 https://blog.professorbeekums.com/2016/10/short-term-goals-and-long-term-goals.html I often think about how to be more productive and making good progress on projects. My progress on creating lessons for professorbeekums.com has not been as fast as I’d like. I started setting daily goals for myself to change that. An example would be finishing 5 lesson steps. This should have been relatively easy since I create outlines for them first. Since my lessons have 25-40 steps, that would equate to a lesson every 1-2 weeks. https://blog.professorbeekums.com/2016/10/a-programmers-adventure-into-ux-design.html Wed, 19 Oct 2016 09:48:00 +0000 https://blog.professorbeekums.com/2016/10/a-programmers-adventure-into-ux-design.html I started professorbeekums.com with very little knowledge about UX Design. The most obvious solution to that problem is to learn. Yet startups are rife with examples of folks trying to do things themselves when they should have hired a professional. It is human to judge things by their appearance so having poor UX can be a huge blocker to gaining users. For something so critical, it makes sense that I should have hired someone. https://blog.professorbeekums.com/2016/10/how-to-handle-data-migration.html Wed, 12 Oct 2016 18:17:00 +0000 https://blog.professorbeekums.com/2016/10/how-to-handle-data-migration.html Data is an important part of any web application. Whether it is a user’s data, such as login information, or the application’s content, such as a blog post, software developers spend a lot of time figuring out where to put data. Software developers are also people though and people make mistakes. What happens if a software developer chooses a poor way to store data? Anyone can make a mistake like this. https://blog.professorbeekums.com/2016/09/the-value-of-unpredictable-work.html Wed, 28 Sep 2016 02:14:00 +0000 https://blog.professorbeekums.com/2016/09/the-value-of-unpredictable-work.html One stressful thing about software development is that it is not always straightforward. Sometimes we build things that are similar to other things we’ve done in the past. The work is more predictable because we have a clear idea on what’s involved. Think of it like writing a blog post about something you are an expert in. There’s still some challenge in structuring your words to be coherent to others, but at least you know all the main points you would want or need to cover. https://blog.professorbeekums.com/2016/09/switching-costs-in-software-development.html Sat, 10 Sep 2016 19:17:00 +0000 https://blog.professorbeekums.com/2016/09/switching-costs-in-software-development.html Switching costs are an important part of software development. When my software relies on one service, the amount of time I have to spend moving it to another service is called a switching cost. In general, you want these to be as low as possible. The reason is that if the service you are dependent on ever becomes unsatisfactory or even harmful to you, then you need to be able to switch to a competitor service. https://blog.professorbeekums.com/2016/09/results-from-being-on-front-page-of.html Sat, 03 Sep 2016 11:05:00 +0000 https://blog.professorbeekums.com/2016/09/results-from-being-on-front-page-of.html A couple of nights ago I decided to put a post I wrote in July on Hacker News just to see how well it would do. I didn’t expect much so when I suddenly saw 800 page views on my blog 30 minutes later, my first thought was “am I getting crawled by some bot?” I quickly looked at the referrals and noticed that a whole bunch came from Hacker News! https://blog.professorbeekums.com/2016/07/job-descriptions-should-be-better.html Thu, 14 Jul 2016 23:54:00 +0000 https://blog.professorbeekums.com/2016/07/job-descriptions-should-be-better.html Job descriptions for developer roles rarely tell you what they should. The whole point of them is to provide a candidate a description of what a position is like. I’ve looked at close to a thousand job descriptions and have helped write a few. Job description writers, including me, have a tendency to come up with something “safe”. We fill job descriptions with text that sounds great, but says nothing tangible. https://blog.professorbeekums.com/2016/06/technical-debt.html Sun, 26 Jun 2016 17:09:00 +0000 https://blog.professorbeekums.com/2016/06/technical-debt.html The subject of technical debt comes up often in software development. It is better to have something done sooner rather than later from the perspective of the project. Yet, this assumes all things are equal, which is rarely the case. Often a developer will have a choice: the short term path or the long term path. For example, a task can be done in 2 hours with one implementation. A different implementation will take 6 hours. https://blog.professorbeekums.com/2016/05/the-hardest-bug-i-have-had-to-fix.html Tue, 24 May 2016 23:30:00 +0000 https://blog.professorbeekums.com/2016/05/the-hardest-bug-i-have-had-to-fix.html A topic appeared on Quora about the hardest bugs people have had to work with. This was mine. I spent years blaming compilers, libraries, SDKs, etc for my bugs only to find out it was my own fault. This ingrained in me the habit of always blaming myself first. That ended up hurting me with this one bug that did end up being a third party. Context: I inherited this major system where the original developer was no longer with the company. https://blog.professorbeekums.com/2016/05/teach-writing-code-first.html Thu, 19 May 2016 22:58:00 +0000 https://blog.professorbeekums.com/2016/05/teach-writing-code-first.html Throughout my career as a software engineer, many people have told me that learning to write code is difficult. I challenge this claim. The real difficulty lies in the fact that most people are taught computer science before they are taught to write code. By computer science, I mean fundamental concepts such as the number of bits in an integer or how various pieces of data are stored in memory. https://blog.professorbeekums.com/2016/05/estimating-software-development.html Sun, 15 May 2016 23:14:00 +0000 https://blog.professorbeekums.com/2016/05/estimating-software-development.html I’m a big believer in agile software development. One major part of that is being able to determine a team’s development velocity (a.k.a. how fast the team works) in a period of time. The naive approach is to use straight up time estimates. Task A will take me 4 hours, task B will take me 2 days, task C will take me 5 minutes, etc. Decades of late projects has served as empirical evidence that this does not work. https://blog.professorbeekums.com/2016/03/better-interviews.html Sat, 12 Mar 2016 01:49:00 +0000 https://blog.professorbeekums.com/2016/03/better-interviews.html I recently gave a friend a mock interview. He was trying to prepare for a big interview and needed practice. What was interesting was that here was an engineer that I would have hired in a heartbeat and yet his performance during the interview was incredibly mediocre. His first reaction was “I really need to improve my interviewing skills.” The sad thing is, he probably did if he wanted to get that job. https://blog.professorbeekums.com/2015/12/agile-software-development.html Sat, 26 Dec 2015 01:26:00 +0000 https://blog.professorbeekums.com/2015/12/agile-software-development.html It’d be hard to be a software developer these days without hearing about “being agile”. Agile is a popular software development process. It is intentionally loosely defined, though that naturally leads to many many different opinions about what it is. The spectrum varies from those who think there are some rules that absolutely must be followed in order to be considered agile to those who use it to justify a lack of process. https://blog.professorbeekums.com/2015/11/advice-for-becoming-front-end-developer.html Sun, 29 Nov 2015 12:07:00 +0000 https://blog.professorbeekums.com/2015/11/advice-for-becoming-front-end-developer.html Someone recently asked me for advice for switching careers to be a front end developer. I knew very little about the person other than their college degree was unrelated to the field, they were trying out Free Code Camp, and that they wanted to be a front end developer. As a result, the advice I gave was generic enough that I’m going to post it in case it helps anyone else: https://blog.professorbeekums.com/2022/what-is-software-quality/ Mon, 01 Jan 0001 00:00:00 +0000 https://blog.professorbeekums.com/2022/what-is-software-quality/