A friend of mine recently asked me what five things he should do in order to grow his technical career in a big company. He is not interested in being a big manager, or a CEO. Rather, he wants to be a software expert, an architect, an owner of a technology, and eventually a “Fellow.” I’m not sure I was qualified to give such advice, but I did anyway. This is what I told him. Maybe this will also work for you.

Almost every document you may write in LaTeX format will have a list of references at the end. Most likely, you will use BibTeX or BibLaTeX to print this list of references in a nicely formatted way. It is also highly probable that your .bib file will contain many typographic, stylistic, and logical mistakes. I’m fairly certain that you won’t find the time to identify and correct them. As a result, the “References” section in your paper may appear sloppy. I suggest using the bibcop package, which identifies mistakes in the .bib file and auto-fixes some of them.

The release of ChatGPT 3.5 has changed everything for us programmers. Even though most of us (including me) don’t understand how it works, some of us use it more frequently than Stack Overflow, Google, and IDE built-in features. I believe this is just the beginning. Even though, only Microsoft knows what will happen next, let me try to make a humble prediction too. Below, I list what I believe robots (with Generative AI on board) will do in the future. The further into the future, the lower on the list. I tried not to repeat what GitHubNext is already saying.

In order to reveal errors of higher complexity, automated tests are turned into integration tests that involve external resources in test scenarios, instead of their mocks. While this approach improves test coverage, it slows down the entire build pipeline. This compromises the very idea of automated tests, which are meant to be a safety net and help programmers edit code safely. Splitting the tests into “fast” and “deep,” and then allowing humans to run the former while servers run the latter, might be a good solution to the problem.

How does your team review ideas, project proposals, or paper drafts? Imagine I’m on your team and I need a budget allocated to a new project. I craft a proposal, elucidate the motivation, assess the risks, develop a plan, and then what? Do I create a PowerPoint presentation, present to my teammates for half an hour, answer their questions for another half hour, hear their honest feedback, after which they vote and a decision is made? If this is how things are organized within your team, you risk stifling creativity and motivation.

At times, it might appear practical to execute additional initialization steps for an object after its constructor has completed. However, I’m of the belief that such requirements signal underlying design flaws, such as object mutability, base class fragility, violation of layering, and unfocused abstraction. A constructor should be good enough for all scenarios. If it’s not, refactor the object.

Method overloading is a common feature in many programming languages that allows a class to have two or more methods with the same name but different parameters. According to Microsoft, method overloading is “one of the most important techniques for improving usability, productivity, and readability of reusable libraries.” I disagree. In my opinion, method overloading may lead to less readable code and more bugs, because maintaining two or more implementations under the same name gives rise to concealed semantics, which inevitably result in misunderstandings and functional defects.

When you find a bug in an open-source library that you use, what do you do? You submit a GitHub issue (or whatever ticket tracking system they use). In the issue, you describe the problem in the best possible way, preferably providing a working code example that the author of the library can run locally to reproduce the bug. If you don’t provide them with an executable snippet of code, they will most likely ask you to do so, unless the bug is trivial. I suggest simplifying the workflow and giving them what they want right in a pull request: send them the bug in the form of a disabled unit test.

According to a study conducted by Dariusz Jemielniak in 2007, the majority of programmers perceive their own managers as highly incompetent. We don’t expect our bosses to be coding-savvy—this level of technical competence is not a requirement for an average manager. Additionally, we don’t expect them to excel in Gantt Chart wizardry or adhere strictly to risk management protocols—these are management practices that are not commonly observed in software teams today. Instead, what we do expect from them is the ability to gauge our productivity: recognizing and rewarding the best performers while taking action against those who are less motivated. Unfortunately, this is a management competence that they lack… or perhaps, fortunately.

I don’t know what programming language you use, but my experience of recent coding in Java, Ruby, JavaScript, PHP, Python, C++, and Rust tells me that the principle, which I will try to convince you to adhere to—is universal for all languages. It’s about the naming of test files. It may look to you like a question of low importance, but let me try to demonstrate that it’s not. How do you name your files with test classes? How many of them do you create in the src/test/java directory? Where do you place a class that is used only in a test but is not a test by itself? To most of these questions, the answer most of you would give is “Whatever!” So let’s try to find a better answer.

It often happens, especially in Java, that a few places in the method are potential exception originators. Usually, we make a large method-size try block with a single catch at the bottom. We catch all the exceptions, usually even using grouping. This helps us minimize the noise, which is the exception catching. However, such large try blocks jeopardize maintainability: we are unable to provide proper error context inside catch blocks.

Sometimes we rethrow exceptions. In Java we do this more often than in other languages, because it has checked exceptions. Sometimes we must catch and rethrow a few exceptions that originated from different places in a method. Java 7 introduced grouping of different types of exceptions in a single catch block. But even without the grouping, it is possible to just catch IOException or even Exception and provide a single catch block for all types and all originators (methods that throw). Recently I realized that this is a bad practice. Here is why.

My first academic paper was accepted and published in 1998. My most recent one was rejected by SPLASH just a week ago. I’m writing two papers right now and co-authoring about ten others. So far, my results are very poor: way more rejections than I expected. The key lesson I’ve learned so far: the reason most papers get rejected is not because they are essentially wrong. Instead, reviewers reject them because they have no enthusiasm for decrypting a poorly structured text, even though it may contain potentially interesting thoughts. In this blog post I suggest how to structure a research paper. Take it with a grain of salt though.

A few months ago I made a small Java library, which is worth explaining since the design of its classes and interfaces is pretty unusual. It’s very much object-oriented for a pretty imperative task: building a pipeline of document transformations. The goal was to do this in a declarative and immutable way, and in Java. Well, as much as it’s possible.

I suggested this idea a few weeks ago on Twitter and got mostly negative reactions. That’s why I wrote this blog post, to elaborate on the subject in an attempt to convince you. Here is the rule I’m suggesting: always submit changes to the code separately from the changes to its unit tests. Simply put, in one pull request you modify the tests, maybe marking some of them as “disabled.” You merge this pull request and then make the second one, modifying the code and most probably removing the “disabled” markers from the tests. You don’t touch the body of the tests in the second pull request.

A few years ago I created xcop, a simple command line tool that can check the style of an XML file. It’s similar to Checkstyle (for Java) and Pep8 (for Python), but for XML. It’s pretty easy to use xcop: just run it with a few command line arguments and it returns the list of errors found in your XML file, if there are any. However, some of the arguments may be convenient to have as defaults and instead of passing them through the command line on every execution, we could store them in some configuration file. The question is: What is the best format for this file? YAML, JSON, or TOML? None of them! I suggest plain text.