GopherConSG 2019 Takeaway

First of all, I would like to thanks my employer, NTUC Enterprise for sponsoring me to this event. This is my first GopherCon and I hope there is more to come.

More details about the conference can be found here.

Here are the main points that I have been constantly being reminded in the conference:

Integrity, Clarity then maybe Performance

Make it correct, make it clear, make it concise, make it fast. In that order. — Wes Dyer

No one care about how fast your application can run if it is not even doing the right thing in the first place. It is just wrong. Your application should be doing exactly what it is being asked to do, not more and not less. If a software engineer cannot even figure out what its application is supposed to do, then what is he/she building? Make sure that you understand the business requirement correctly and code to it.

After that is achieved, strive for clarity. Even though your code is doing the correct thing, is it doing it in a way that can be easily understood and maintained in the future? This is the stage where we trying to prevent spaghetti code and magic code. This is really where Go shines. It should be easy to go into any codebase and figuring out what is it doing.

Performance is what Go is good at compared to a bunch of other programming language, at least those scripted language. A lot of Go programmers comes from those background and wanted to harness this power from day one. They wanted to squeeze every single drop of the CPU juice out. But in the end sacrificed the other aspects. Often time, it is just micro-optimisation that wouldn’t really matters. Even worse, we are talking about optimisation in blind. We are taking numbers from other people’s benchmarks result and think this must be applicable to our project as well. We skipped the data collection and we didn’t give our existing working solution enough justice.

What is Software Engineering?

Software engineering is what happens to programming when you add time and other programmers. — Russ Cox (link)

By understanding what is this will help us to answer why we do certain thing in Go. Go is a language created in Google to solve the engineering problem that is being faced in Google. Do we have the same problems that Google is facing? Definitely not all. So should we take all the solutions given by Go? Maybe not as well.

To be honest, I love programming because I like how I can use it to solve the issue I have. But at the same time, I hate programming because of all the Engineering structure around it. I like to be a free man to be able to do what I want. That is not Engineering.

To earn the title of Software Engineer, it means there are things that we need to do and things that we can’t do. We need to have discipline and I believe no one likes that.

I don’t like to submit pull request because that means I would be slowed down on my work and potentially be criticised for the work that I have put long hours. But is this pain necessary? Yes only if I am working in a team with other programmers. Why? Because engineering is a team work. Once the code is merged into central repository, it belongs to the team now. It is not the senior’s work and it is not the junior’s work. It is the team’s.

As an Engineer, we

• Develop secure application. We don’t leak passwords.
• Monitor and guard our code dependencies. Nothing should change unless we ask for it explicitly.
• Use tools for improve our work — analysers/linters.
• Understanding our tools. How Go garbage collections works? Where does our memory live?
• Write test — unit test, integration test.

There is no best/perfect solution

OK. This may not be from the workshop or from the talk. This is just some random chat with various people from the conference.

There is always a better way to do something. We have to know what works for us. No other company or team have the exact same situation as you.

As we are coding, we are at the same time constantly refactoring our code as well. We are adding new features into the code. Those new features might triggers some other changes that are required. Features could be deprecated and we have a chance to clean up our code.

We are worried about get into technical debt. But there will also be technical debt. We have to spend some effort to minimise this but it will never be eliminated.

You don’t have to get it right the first time. Sad truth is you can’t get it right the first time. Because at the same time, the right is constantly changing as well. Just get it done and move on. Embrace the next change — new business requirements, new technology, new ideas. You cannot predict the future so be ready. But that doesn’t mean you should do nothing or do extra today. Just get what needs to be completed with what we have now.

From the book that I have read, stay in the present.