1. Pragmatic Philosophy

Key to success for a pragmatic programmer:

• Always think beyond the context, look at the bigger picture.
• Take responsibility for everything you do
• Communicate, list ways that you can do things better

1. Control of your life oportunity

It's your life, you onw it you run and create it.

If you want to change your job, have an agency that do it for you or apply for new job yourselves.

If technology seems to be passing by, dedicate time to do it.

Be proactive and take the opportunity to do so.

2. Be trustworthy

You take the responsibility of your actions in your career advancement, learning and educations and project.

You are not afraid to admit ignorance or error. When these things happen, deal with it professionally, being honest and direct.

Ownup to our shortcoming (failure)

Make your team trust you

You need to trust your team and your people first to make them trust you.

In a healthy environment, you should be able to speak your mind and rely on your teammates.

Don't be affraid to ask or admit that you need help

Take responsibility

You have the right to NOT take responsibility if it's:

1. Impossible situation
2. High risk
3. Sketchy ethical

However, when you do accept the responsibility, you should be expect to be held accountable for it.

Don't blame something or someone or make up excuses. It's up to you to provide solutions, not excuses.

If there is a risk, you should have a plan for unpredictable risks.

[!note]
Provide OPTIONS, not excuses

Before approach your manager tell something that can't be done. Run the conversation through your mind. They would ask "Have you tried this…?", "Have you consider that…?".

Provide the options and what can be done to rescue the situation.

3. Don't leave "broken windows"

A broken windows is software failure / bugs. A broken windows can degrade the quality of the house significantly. Same concept applies to software.

As the develper, we should not leave any "broken windows" in our code. This includes hacky-fix solutions or known bugs but not fixing it.

If there is no time to fix it, we should:

1. Leave a comment to address the code
2. Subscribe to a dummy data instead
3. Create a function to fix and display not implemented.

If the code has no broken windows, you will value that code more.

Don't cause collateral damage

If there is a problem, try to fix it without causing any additional damage to the software and user.

4. Be the catalyst for change

Even if you know from A-Z the step by step to fix it correctly, asking the team or permission would cause a lot of delays.

To persuade people to your solution, you need to.

1. Work out what you can ask for
2. Show your teammate, let them be curious
3. Pretend it's not important, say something like "Of course, it would be better if we add …"
4. Sit back and see if people wants to add that feature in

[!important]
People find it easier to join an ongoing success than to agree for changes with risks

[!tip]
Be the catalyst for changes

Be aware of the big picture

Sometimes focusing purely on one feature could lead to broken windows in other features accidentally.

Therefore, you need to always be aware of what's going on in the project, looks out for broken windows in many aspects.

5. Produce good-enough software

User would rather deal with a software with some rough edges then wait for years for it to be shiny.

Releasing beta or early access would let the user have a chance in their say and use that to avoid "broken windows"

Know when to stop

You often find a software or product bloated with a lot of features. Hardwork is ruined if you don't know when to stop.

6. Your knowledge is not an asset, it's your ability to learn

Your knowledge is expiring assets as new languages, techniques and environments are developed

Your ability to learn new things is your most important assets

Invest in your knowledge portfolio

Therefore you need to invest in your knowledge portfolio by keep studying and updating yourselves with new technology.

1. Study regularly
   • Even if it's small amount daily it can be beneficial
2. Diversity is key
   • The more different things you know, the more valuable you are
   • The more technologies you're comfortable with, the better you will able to adjust changes.
3. Manage risk — don't put all your eggs into one technology
   • Don't just be known for one thing, it's high risk. You should be diversed in your technology.
4. Balance between stability and cutting edges technology
   • Learning new things could be risky but it can be paid off later
5. Review what you learn and rebalance
   • New technology that you learn might be stone cold, Brush up into the technology that you haven't touched in a while

With all of these, the easiest one to do is to "study regularly"

Set yourself some goals

Here are a few suggestions

1. Learn at least a new language every year
2. Read technical book each month
3. Read non-technical book that could potentially benefit your career
4. Participate in meetups to expand your networks
5. Experiment with different environment (windows, linux, mac, makefiles, IDE, …)
6. Stay current (mediums, news, podcasts)

[!important]
It's does NOT important if you ever use these technologies that you learn or if you ever put it into your CV, the process of learning will expands your thinking and increase your ability to adapt changes.

Try to apply different concepts that you learn in your current work and project, even if your current project does not use the same technology. Perhaps you can borrow some ideas.

When seeing or hearing of something you don't know, find out.

Take new information and personal challenges and find out, understand about that technology. If you can't find the answer yourselves find someone who can. Don't let it rest.

Critical thinking

Question what you read and hear, apply critical thinking to see if the idea is valid. Don't listen to random people advices without proof and critical thinking.

Whenever you face an idea or suggestion, ask yourself:

1. Ask five "why?"
   • Ask "why" at least 5 times, this is to dig deeper and deeper to find the root cause
2. Who does this benefit?
   • Find out what is the purpose of this idea, suggestion and how does it benefit you or someone else.
3. What is the context?
   • What's the prerequisites? What's the consequence?
   • What's the benefit short and long term?
4. When and where this would work?
5. Why is this a problem?

7. Communicate

Treat English as a programming language as well. Write natural language as you write code:

• DRY
• ETC

This is to make your communication better and more efficient

Know your audience

When doing a presentation of your work, ask for feed back don't wait for question. Look at the body language and facial expression, you should be able to know if the audience get it.

"The meaning of your communication is the response you get"

Know what you want to say

Plan what you want to say, an outline. Then ask your self "Does this communicate what I want to express to my audience?"

When you're faced in the important meeting, jot down the ideas that you want to communicate and have a strategy how you would communicate them effectively.

Choose your moment

It's important to know if it's a good moment to discuss something.

For example, if your manager is about to leave the office and commute home it's probably not a good time to do it.

However, if your manager is stress out about an issue that is affecting the team, she/he would be more receptive to listen to your idea on how to solve this issue.

Always ask yourselves: "Is this a good time to talk about …?"

Choose a style

Adjust your delivery to fit your audience. Some people wants "just the fact", however some other might want a bit of small talks before getting on to business.

You need to consider your audience:

• Are they newbie?
• Are they experts?
• Do they need hand-holding or just tl;dr?

If you don't know what they're looking for, ask.

[!tip]
If someone need a paragraph to describe something and you can't see a way to do it, tell them so.

Make it look good

A good idea without a good presentation will not be perceived as good idea.

Try to convey them in a professional way. Because they deserve it.

Involve your audience

Involve your readers with early drafts of your document, get their feedback.

Be a listener

If you want people to listen to you, listen to them first — even if it's a situation where you know the answer, have all the information.

If you don't listen to them, they won't listen to you.

Encourage people to talk by:

• Ask questions
• Ask them to restate the discussion in their own words

Get back to people.

Always respond to emails and voicemails even if the response is simply "I'll get back to you later".

This is to keep people informed.

[!tip]
It's both what you say and the way you say it

Documentation

Embrace document as part of the development process.

Add comments to modules and exported functions to give other developers informations when they use it.

However, don't over document something. Only use commenting to discuss why something is done, its purpose and its goal.