Good to great
(for software engineers)

John Gialamas
November 2021

Who Am I



Operations Manager

Proxy Product Owner

Rapidly growing software ecosystem

Aspiring engineers

Great companies


The "Software Engineering Book of Knowledge"
(Bourque et al. 2014),
 attempts to enumerate everything a software engineer can and should know to be competent


  • Skills
  • Knowledge
  • Attitude

Research on software engineering processes also implies skills required by engineers.

Various guidelines, methods, and manifestos,

suggest many specific ways of

and deciding

that are essential for productive teamwork.

Ask a senior Developer or an HR Manager.

"Are some attributes more important than others?"

Attributes of great Software engineers

Attributes of great Software engineers

In general, the most important are:

internal personality traits,
ability to engage with others,
technical capabilities,
and decision-making skills



Not just writing code.

  • conflict resolution

  • bug triaging

  • information seeking

  • Mentoring

  • Thinking out of the box

(Research shows that PhD holders have negative relationships with
asking for help and challenging others to improve)

Do not be afraid to ask for help!

Find your mentor.
Join Communities

Offer help!
Be a mentor.
As Mr Kakarontzas said, PairProgramming is very effective

Can you find a solution to any problem at any time?

Ask for Requirements

Learn to say "No"

What Language?

Try many languages/frameworks...

and then
find one what makes you passionate!

(or the latest?)

The internet has massively broadened the possible space of software developers' careers.

But this broadened the competition too.

What is the market looking for?

(your UVP)

"What you do during your breaks, should be your thing"
-Austin Kleon

How to obtain it?

side hustles
pet projects
(not from schools)


How many hours?

Analytical Thinking

Descriptive vs Predictive vs Prescriptive


Programming is 99% self-taught



Practice with friends’ debugging. It exposes you to someone else’s coding style. Learn something from everyone.






Read a lot of Good code. And then read some spaghetti code. Learn from the differences






Always Up to date!!
(What is new and hot?)


Digital knowledge!
Subscribe to newsletters and tools for informing yourself

Read some books.


The things that you used to do five years ago that made you
successful doesn’t matter anymore.
(in fact, they can get you into trouble right now)

Deal with two (or more) sets of customers/POs at once?

Communication skills are needed.
Empathy is also needed.


Respect the business Decisions.

Always try to advise though.


Speak their Language.
(they pay you, and they will pay for your ability to attract funds)





This way everyone will know what the others are working on.


Transparency is crucial!!!

(Also, do not take your work at home. especially on the weekends!)


Stakeholders must participate, so they feel invested and committed to the strategy.

Very good at one
and decent knowledge on some other fields



Malcolm Gladwell, Outliers




You cannot be great if you are constantly re-inventing the wheel or using out of date



I would never hire someone who:

Do not become any of these

Theorist Developer

Can tell about any framework or language, but he cannot use it in real project conditions

Stackoverflow Developer.

Just copy paste.
No knowledge/investigating why this works.

No problem solving ability.

Perfecionist Developer

he/she won’t start any task before this is completely specified in every little detail

Overconfident Developer.

give them any task and he will respond that he can EASILY implement it

Business Logic is good, but...

Businessman Developer

By gaining some theoritical BUSINESS knowledge (mainly from books), he starts thinking about creating his own startup/venture.

Manager Developer

When someones fails as a startupper, and returns to work as a developer.
He cannot work with an engineering mindset anymore.

Trouble maker.

He needs to solve problems that doesn't exist.
Probably, he tries to create some, in order to be a problem solver.
What is bad for the hive, is bad for the bee.


Fix only what is broken!

Some more "rules"

Long variables, easy to read.

Self-documented code.

No single letter variable.

Early exit (when you know there is nothing more you can do).

Do not overcomplicate. If it is easy to understand, go with it.

Some more "rules"

Do not overoptimise. The real scenarios are not in front of you. Fixing something that isn’t broken, only makes you spend more time on it.

Be strict with your code and tolerant with others code.
Write code for yourself but for 5years ago.
(Would you understand it 5 years ago?)


Test Test Test!
Experiment experiment experiment)

Scalable Code

Deep work.

Be distraction free === Notification-free


Avoid Complexity

the greatest impediment to a software company’s growth and profitability.


Thank you!


You can see the whole presentation here


What distinguishes great engineers from ordinary ones

By Any App

What distinguishes great engineers from ordinary ones

  • 364