What do software developers do on vacation

Linux and open source

If you look at how developers see their own mistakes, that's proof that software development is an art. The way in which opinions on painters, architects, writers and poets diverge is very similar in the world of software development: Developers usually only agree that functioning code is the essential requirement for their work. And even in this regard, there are deviants who can live with existential programming errors - as long as the software bugs remain hidden from the users.

The debate about the correct way to develop software is essentially based on empirical values. If a developer condemns a certain practice X, it is mostly because someone in Office used X and it ruined an evening, a weekend or even a vacation. At first X looked like a good idea, but then unfortunately one or more errors of thought emerged.

Those affected want to warn the world about X now. New problems arise, however, when the opposite procedure - Y - has inherent pitfalls of its own. Software developers who switch to Y in order to avoid X and end up in a similar valley of tears as their colleagues then usually don't think much of Y anymore.

Is there any hope of bringing X and Y together? This is highly unlikely within a developer team - but that doesn't mean you can't learn from the mistakes made by Groups X and Y. With the help of the dirty dozen of software development, we'll show you how programming doesn't work - and at the same time start demonstrating that coding is actually an art. An art that requires a rich skill set to find the golden mean between problematic extremes.

1. Go to ASAP for the coding basics

Leaving aside the basics of software development is the quickest, easiest way to sabotage your own programming work. It is particularly often overlooked how arbitrary usage behavior can affect the software: Does entering a 0 flow into a division operation? Is the text entered the correct length? Has the date format been checked carefully? Is the username compared with a database? Every small mistake in these areas leads to the software failing.

There are some developers who simply cover up these pitfalls with an "error catching" function: The error is saved in a log file and outputs an error code - someone else can then take care of remedying it.

2. The devil in the details of development

On the other hand, software that is overloaded with too many details can become a chump. Checking a few zeros won't make much of a difference - however, it becomes problematic when the application transforms into code-poured paranoia and checks all possible "doors" over and over again.

If such compulsive control scenarios also make network communication with a website necessary, the software can come to a complete standstill. An example that every user probably knows: Some applications slow down many times over if there is no WLAN connection because they are constantly looking for a hotspot that simply does not exist.

The challenge for software developers is to design the code layers in such a way that input data is checked when it is first entered. That is, however, much easier written than done. If there are many developers working on a library, or if only one person is responsible for programming, it becomes quite difficult to remember if and when the pointer was checked.

  1. Product & project manager
    In general, developers don't particularly appreciate it when someone tries to explain to them how to do their job. But because product and project managers often lead development teams, that's exactly what happens. That can lead to discrepancies.

    David Fox from devRant also has an opinion on this: "Ultimately, in most cases, product and project managers are in some way the 'owners' of projects and processes without being involved to know the daily challenges and problems faced by software developers. "
  2. Bosses
    Just like product and project managers, development or engineering managers are responsible for leading teams of developers and ensuring that projects are completed on time and under budget.

    "In some companies, situations can arise where the boss is also a member of the development team. Especially if the boss was a developer himself and becomes boss after a promotion, there is potential for conflict," notes Fox .
  3. Recruiters
    Software developers don't have to actively look for a job themselves in order to be harassed by recruiters and headhunters - thanks to the shortage of skilled workers. It will be very difficult to find a developer who has not yet fallen into the clutches of recruiters.

    David Fox especially sees the persistence of the recruiters as a problem: "They call, email and they just won't leave you alone - even if you're not looking for a job. And even if If you are looking for a job, many recruiters tend to make irrelevant job offers or recommend positions whose profile does not fit at all - for example a job on the other side of the country, even though you are not ready to move. "
  4. documentation
    If there is no documentation, the software developers complain. If it's too much, they complain, and if they have to do the documentation themselves, too. Even the developers are complaining about the way other people handle the documentation task.

    At this point, all developers finally agree, as Fox emphasizes: "Software developers want detailed, well-written and accurate documentation - but they don't want to do it themselves."
  5. Meetings
    Meetings are a problem not only for everyone else, but also for software developers. Especially when it comes to completely unnecessary, time-consuming and utterly boring get-togethers. As Fox explains, devotional items with the inscription 'I survived another meeting that should have been an email' are now also available.
  6. Coworking spaces
    With the rise of agility, flat hierarchies, collaboration and teamwork have become part of everyday life in companies - especially for software development teams. But it is precisely these people who usually find it difficult or impossible to cope with their work in an open-plan office - at least that's what the devRant figures say.

    David Fox explains: "There are just too many distractions: colleagues are chatting, meetings are missed, phone calls are overheard. There are also a number of complaints about coffee in the office and other amenities - or that Opposite of that. "
  7. colleagues
    Self-explanatory: everyone has a colleague whom they particularly value. Not.

    In the case of software developers, the aversion to colleagues is usually based either on the poor quality of their work or an ego that is completely out of synch, reveals David Fox.
  8. Job interviews
    When a software developer is looking for a job and is invited to an interview, there is usually something to complain about afterwards:

    "The developers get just as angry as one with stupid questions or the solution of completely unpractical tasks in the interview Interlocutor who doesn't even know what a developer is actually doing, "says Fox.
  9. Errors & bugs
    Software developers deal with errors and bugs day in and day out. That's why devRant founder Fox believes that developers think differently on this matter:

    "Most other problems don't get a positive resolution, but bugs and errors can be fixed and that feels good."
  10. Quality assurance
    Quality Assurance (QA) - or quality assurance - is a critical part of software development. Still, software developers often complain about the same things about QA experts as they do about product and project managers, according to Fox.

    "Quality assurance gets its hands on the product or project when the developers have completed it. This is why they often do not understand the hurdles and workarounds the developers had to overcome in the development process. Obviously, it also happens regularly that QA people are asking developers to revise areas that they could do themselves. "

3. Software development out of control

All too often, software developers take their own actions to ensure that programming ends in disaster - namely by having no control over their code.

Mike Subelsky is the co-founder of OtherInBox.com and an advocate for "code-order". In other words: There should only be one place within the program code where each individual task is stored. If there are several, the chances are good that someone will make a change at one point without thinking about the other (s): "After working with a code base for over three years," Subelsky chats from the sewing box, " What I regret most is that I didn't build the code modularly. That's why I had to learn the hard way how important it is to adhere to the single responsibility principle. "

As you may have already figured out, Subelsky is a Ruby on Rails programmer. This framework favors the creation of a program code that is as lean as possible because it is assumed that the majority of the software structure can be classified in known patterns. Ruby on Rails Developers often summarize this philosophy as "Convention over Configuration".

An example to clarify the principle: The software assumes that a created object of type X with two fields "A" and "B" is automatically created in a database as table X with two columns "A" and "B" . The naming is kept in one place so that no problems arise if an individual fails to keep all configuration layers in sync.

4. "The development framework regulates this"

Sometimes tools whose marketing capabilities border on magic can also lead to general confusion. Due to the abstraction of functionalities and the assumption that they already know what developers want in advance, frameworks can leave developers in the rain at a loss when it comes to determining exactly where the error is in their program code.

G. Blake Meike is a freelance software developer and just one of many who see a dependency on automation tools like Ruby on Rails as an obstacle when it comes to programming cleanly: "Convention is something that, by definition, has nothing to do with code If you don't know the exact rules of Ruby on Rails, for example, you won't be able to understand exactly how the framework works. This can always lead to new problems. "

The use of development frameworks makes for "beautiful" code - but it is often difficult to understand, edit or expand. Or - as software developer Mike Morton puts it: "Frameworks lift you up to 90 percent in a comfortable chair towards the summit. But that's it. To be able to conquer the last ten percent of the ascent, you have to think ahead and both oxygen and have also brought climbing hooks. "

5. Don't trust any machine!

If software developers simply assume that their end devices will already "do" the right thing, this can lead to serious security weaknesses. Program code that was designed for a browser, for example, can be rewritten by it in such a way that any kind of arbitrariness is possible. If the software developer doesn't check all incoming data, things can go wrong.

For this reason, some of the most common attack patterns by criminal hackers are based on the assumption that quite a few developers transfer data into the databases without checking. This works well until an attacker deletes the entire database with a simple command. And that is by no means the only way to outsmart servers: online surveys are more or less an invitation to generate bias, and buffer overflow attacks are still the easiest way to permanently damage software.

If three or four - supposedly negligible - security gaps are "connected in series", considerable security risks can arise. For example, a software developer could create a file on the assumption that the directory permissions are sufficient to prevent errors. Another developer is now opening the permissions to remove a bug. Both processes do not necessarily represent a risk on their own - if they come together, the client can become unpredictable.