For example:

  • After I've learned about SQL injections I realized that in past projects I didn't check user inputs for SQL injections.
  • After I've learned about PKCE I realized that in past projects I didn't use PKCE in OAuth 2.0.

Each time I have these enlightenments, I feel bad about my past projects. My inner voice says to me: "How dare you event start working on it if you didn't know this?".

Is it just normal flow of how software developer grows? If so, does that mean that we legalize wrong things we do in our projects?

In the other hand "we don't know what we don't know" and I think this shouldn't stop us from doing the job.

  • 3
    No one is born with all the knowledge. You learn as you go and will make mistakes. The problem is when you don't learn from your mistakes. Commented Mar 18 at 13:48
  • @MetalMikester tell that to construction or aviation engineer
    – Basilevs
    Commented Mar 18 at 14:00
  • 1
    Are you working as a sole developer or as part of a team? In a professional environment, these things should be caught as part of the design and/or code review process. Commented Mar 18 at 14:06
  • 1
    @Basilevs: that might be seen as related, but it is definitely a different question.
    – Doc Brown
    Commented Mar 18 at 14:31
  • 1
    @Basilevs, when was the company lawyer or company secretary, last expected to look after their own burglar alarm? There are many reasons why software development should have better professional training, but in the case of computer security, the real issue is that it shouldn't even be regarded as the same occupation as computer programming.
    – Steve
    Commented Mar 18 at 14:53

4 Answers 4


We all make mistakes, and feeling bad about them is quite normal. However, at some point it is better to put the bad feelings aside and look at this from a professional point of view.

Do you have warranty or maintenance obligations for these past projects which are still in place? If you are the software vendor, you should consider to make a risk analysis, and in case the risk is high enough your design flaws could cause some serious issues, you hopefully decide to fix the issues, inform your customers and provide an update. In case you are just one team member in a larger software organization, you can inform your superiors and leave this to them.

If you don't have any warranty obligations for these past projects, then don't bother - just learn from your mistakes. Software for which security breaches can cause severe damage should always be subject of an obligation of the software vendor to provide updates. It is the customers responsibility to establish a contract or other kind of measures which gurantees them to get these updates. If they forgot this, sooner or later they will learn it the hard way they have to care for updates.

When you want to establish a long-lasting customer relationship, or don't want to risk loss of reputation when someone else detects your faults at a later point in time, you may consider to deliver an update even when there are no warranty obligations.

All-in-all, these are business decisions, not really software engineering decisions, so treat them as such.


I wouldn't worry.

If you hired a person to design say a biscuit production line, you wouldn't typically expect that person to involve themselves in the problem of what happens if someone feeds arbitrary sewage into the line instead of good food ingredients, or attacks the machinery with hammers, or steals the ingredients from the forecourt.

You especially wouldn't expect a (typically) young and inexperienced engineer, working single-handedly, to design a machine (or an ordered factory environment) that was completely resilient to all those kinds of malicious attacks on the biscuit-making machinery. It would be the responsibility of a large organisation of people, including senior managers in all kinds of specialist functions, and reinforced by the facilities which the state provides (who provide police, judiciary, buildings inspectors, health and safety inspectors, factory inspectors, etc.).

Experienced programmers might be able to avoid the most blatant dangers and invitations to mischief, but only because they're more familiar by rote with a popularly-known list of bad practices. These are typically evangelised by public figures, who are either security specialists in the computer industry, or they are corporate managers who are themselves the most recent victims of a specific security hole. Or, like with Bobby Tables and SQL injection, a comic strip/meme that has become well-known because it is funny.

Experienced programmers are not much better than novices at analysing and solving overall security from first principles, which is a deeply expert area.

So don't be so hard on yourself.


I think there is some misunderstanding on your side. If you don’t realise that you did things wrong in the past, that’s when you should worry.


This is not a personal problem, just a symptom of a young and unrefined industry. Laws for established industries prevent them from producing a subpar product. They have standards, certifications, licenses, inspections, mandatory education.

In a hypothetical future, education and tooling would be mandatory and a business would lose their license for leaking customer data or failing to account for CSRF.

None of that applies to software engineering yet.

Consider yourself an artisan - you produce an "art and craft" product without any guarantees or protections for the end user. As long as you and your end user agree on a level of quality ("provided as is"), there would not be any anguish.

It is important to remember, that "artisan" approach does not apply when working for health and safety industries.

  • In that future, you would be fired with demerit and would sue the university for uncertified cirriculum.
    – Basilevs
    Commented Mar 18 at 14:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.