Speech writer secrets

I enjoyed this humorous talk on public speaking. Some of the advice feels gimmicky, but if you compare it to what you hear when presidents and leaders speak you’ll see that they all use it, well with a few exceptions.

The main points are

  • Be confident
  • Combine 3 breathless sentences for dramatic effect.
  • Repeat words three times for impact : “My people, my people; my people“.
  • Use balance: “In this life, and in the next”.
  • Reach for unique metaphors: “Love is a fruit in season at all times and in reach of every hand.
  • Exaggerate a bit for effect not to cover up the truth.
  • Rhyming. It tricks the brian into being comfortable with the information given as it sounds so right.

Go ahead and watch it for yourself:

Link to video if the embed above fails:
https://www.youtube.com/watch?v=bGBamfWasNQ&feature=share

My notes from the talk on how to maximise success

Carla Harris, Vice Chairman of Morgan Stanley Wealth Management, explains exactly how she got ahead in a male dominated industry.

Here’s what stood out for me:

  1. Your authenticity is your advantage.
  2. There are two currencies when it comes to success. 1 Is performance currency and 2, relationship currency. You need both to succeed, but only relationship currency get’s you to the pinnacle.
  3. She pointed out how doubtful some people are. She learned a thing from her white male colleagues. They were “frequently wrong, but never in doubt”, in other words they had confidence all the time.
  4. Perception is realities’ cop-pilot. What people perceive you to be is often how they think you actually are. You need to make sure that you make it easy for people to perceive in the same good way you do yourself. You can train others on what they should think about you. How should people describe you when you’re not in the room?
  5. If you offer that which is not valuable you will not get any reward for it.

Watch the video below

In case the video fails to show, heres the link : https://www.youtube.com/watch?v=yflSZODY6YU

Software Complexity

It is easy to define software complexity, but not so easy to define how complex a specific piece of software is. There have been lots of work in academia to find ways to describe it, but these approaches are not generally applied. Complex software directly refers to its effects on the human mind.

The software industry has a few methods for evaluating complexity. A well-known method is Cyclomatic Complexity, by Thomas J. McCabe, Sr. Cyclomatic complexity plots the number of linearly independent possible paths through a program. The reason why more possible paths introduce complexity is this; when changing a program, the maintainer needs to understand and keep those paths in mind to avoid introducing new bugs. Our human brains have limited capacity for the number of options we can consider at the same time.

Along with looking at the actual program, you must also consider the context. One must weigh in the problem it attempts to solve, the domain it targets, and a few other factors. In some cases, you can simply glance and call it complex, but for others, complexity is revealed as you dig deeper.

All software starts as a set of requirements, and this initial phase is often where we sow seeds of complexity. Software Requirements are usually initiated by people who know what they want, but not necessarily how to build it. This may result in oversimplification of the efforts required, which may lead to shortcuts resulting in unwanted complexity. The requirements phase is the first place to root out complexity.

One can’t always blame those who create these requirements, as they are often at the mercy of a complex problem domain. Think about aerospace or naval technology as examples. Certain fields are by nature complex and thus making the systems they produce have a higher level of necessary complexity.

There are two complexity flavours, according to academia. The first one, obviously named, is Essential complexity. It is a level of complexity that is absolutely required for the system to function. The next one, also accurately named, is avoidable complexity. Though these names are clear, figuring out which parts are avoidable takes a lot of time. Software needs to be taken on the road and through all its paces. We’ve seen people use software in ways the designers haven’t thought about forcing one to rethink avoidable and essential. Essential to whom? Avoidable for whom?

Simple processes can produce complex outcomes. Only the user experiences complexity. Why are we writing software? Is it for Business, business systems, end-users, or the next maintainer?

Attributing levels of complexity is a very subjective act. You should take into account all dimensions involved in a systems life cycle.

It is easy to think that complexity is a problem, but as long as a piece of software addresses a set purpose, the complexity is secondary. If the goal is for it to be simple, complexity is primary.

Why is Atlanta burning?

My colleague Charles wrote about the uprising in America, more specifically Atlanta.

“Tell them that a Black life should be worth more than a pane of glass, or a store…”

Charlescearl's Weblog

When they ask you why Atlanta was burning last night, tell them it was an uprising.

If you want a quick answer, you can quote the economist Thomas Piketty

Every human society must justify its inequalities: unless reasons for them are found, the whole political and social edifice stands in danger of collapse.

Capital and Ideology, Thomas Piketty

Tell them that a Black life should be worth more than a pane of glass, or a store, but that nearly a thousand Black lives in Atlanta’s surrounding counties have been lost because a governor refused to take action to protect them from deaths of inequality.

There were fires and police beatings taking place down on DeKalb Avenue not far from where I live. If you know Civil War history, this was where General Sherman began his march to the Sea in 1864.

They will tell you that this 1864 march this…

View original post 758 more words

PHP is just fine

hammers in a row

A programming language starts decaying right after inception. The idea that a language is perfect soon hits the harsh reality of users running into situations the author(s) have not anticipated.

The law of the instrument mentions the following statement by Abraham Maslow:

I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.

It takes a long time to learn how to use a tool effectively. This leads programmers to use a familiar language when they are confronted with building something new. I think this is true for all tools. One of my hammers, the PHP language, has been around since 1994 and it is being used by 78% of all websites (source: W3Techs). PHP is showing its age and the idea of it being replaced by something new and fresh has been gaining momentum for a long time.

When you look at any programming language, given enough time to mature, you will notice the question of retirement come up. You can see how this is just a google search away: “Is this language dead?“. I found questions about all popular programming languages.

The concept of dead languages reminds me of the language I had to learn as a student, COBOL. It was created around 1960, and now it so old that modern technologists have completely forgotten about it. No-one is raving about how amazing it is, no new courses are popularly teaching it and most people just want it to go away, but in the midst of all this, COBOL is still alive and is being used by many financial institutions. COBOL solves a very real business problem and so does PHP.

The simplicity that PHP affords those who learn it and the ease of getting from 0 to 1 makes it a heavyweight in the website programming languages league. It allows people to test out ideas faster and cheaper than any alternative out there.

This old programming language is just fine for building websites and web-based solutions. It can be the final solution or act as a prototyping tool. It is a gateway to the world of programming. A way to think about problems and address the needs of your users.

Relevancy has everything to do with the problems you solve and nothing to do with the tools you use. If you solve relevant problems with ancient tools, you’ve still solved a real problem. Yes, the tools can make certain classes of problems easier to deal with but ease is relevant. PHP was my gateway into the world of programming and a way to understanding and learn other languages.

This old language is fine for solving problems, great at being used as a hammer for most nails and great as a teaching tool while learning about its weakness and where it may not be the best tool for the job.

The main thing I take away from all the language conversations is this. We have customers and clients who need our skills to solve problems. If the Hammer works use it, if not find a working tool quickly and solve the problem and don’t allow perfection to stand in the way of good enough.

Highlights from Everybody Writes

Beth Dunn went from being an unemployable writer to a writing career that speaks for itself. In her talk, “How to Be a Writing god“, she hammered down the idea; disciplined writing is the only way to improved writing. Her story, alongside the Author, Ann Handley’s simple advice, makes it clear; every professional should take writing seriously.

Most people dislike writing. Maybe it’s all that forced writing we had to do in school? It was interesting to see the book encouraging us to let go of any writing advice you received at school.

“The difference between Good writing and bad writing is trying, trying and trying again”

In this book, you will discover many valuable ideas, though one stands out for me, the writing process; a detailed set of steps that shows you the way a finished piece when all you have is an idea.

Writing process

The following steps helped me. I’ll share a quick summary with you. Follow it in order and see the results for yourself.

  1. Have a clear goal. Write this goal down as the first thing on your draft and keep it at the top. Refer back to it often as you work on the piece.
  2. Restate your goal within the context of your reader. This is the more difficult part and I’m struggling to do this, but I think with practice it may become easier.
  3. Do research. Seek out data or others who have written about the topic or anything related to your goal. This helps give your post more credibility and builds trust.
  4. Organise your findings and thoughts. I normally just create one-sentence paragraphs in a draft. Write down everything that comes up related to your topic.
  5. Remember to write to one person. People hardly ever read in groups and if they do it will be only one person reading at a time so think about writing as a conversation.
  6. Create the Ugly first draft. Write like no-one cares. Just write. Don’t even care for structure. Just take the thoughts you have and expand on them as much as you want to.
  7. Walk away, do something else, give yourself space away from the content. Create another draft for another post.
  8. Rewrite the draft. I must share with you that I don’t really do this. I write on a computer and simply manipulate the draft document.
  9. Give it a great title. One that captures the essence. One that tells the prospective reader exactly what to expect. Don’t mislead your reader, trust is more valuable than views. Most times my writing starts because of a title that frames the idea.
  10. Have someone edit it. This is mainly for commercial content. I use Grammarly to check that all is in order.
  11. Add a call to action. What do you want the reader to do next?
  12. Have a final look at it and check that it reads clearly and is easy on the eye.
  13. Publish! Don’t allow perfect to be the enemy of good enough. This is just one step in your journey, so keep publishing.

The writing process helps you on a very practical level, but when you’ve got this process down there are many other important tips for writers.

To wrap up, I’ll share some final thoughts, but for the full experience, you’ll have to read the book.

3 Critical approaches to writing

1. Writing is a service to your users. A practical example of serving would be to place the most important parts first, providing the most value upfront. This is out of respect for the reader’s time making it easy for them to understand what you want to highlight. The same applies to sentences. First, give the content and then back it up with context. Instead of “According to John, mocking others is foolishness” write ” mocking others foolishness, according to John”. Respect the reader, keep writing to the point and remove cruft that doesn’t add value.

2. Discipline – All great writers practice their own version of a writing discipline. The main take away here is to practice daily, if that’s not possible set time a side on a weekly basis.

3. Show don’t tell – Most people do not appreciate being told what to do, so the better approach would be to make suggestions and provide great real life examples. Give them the example and let them decide what to do with it.

Conclusion

I hope some of the lessons I’ve learnt are applicable to your situation and I hope it inspires you read Everybody Writes for yourself. You can find the book here: Take A lot | Amazon

Choose boring technology

I read an interesting article about choosing boring technology. Here are my key take a ways:

  • New shiny tools have this one big problem. They have more unknowns than tools that have been around for a while.
  • Boring is anything that has been around for a long time that works and have been tested at scale. Examples: MySql, PHP, Python. Boring is not bad.
  • Boring technology may also be newer but it is the default stack in any organisation.
  • Boring can save you time and money. Boring should be recommended.

Read more at https://mcfunley.com/choose-boring-technology

Remote spelled out is TRUST

2 planes in tandem with people performing stunt on top of them.

Bright and I had a very interesting chat about remote work, because of the COVID-19 lockdown situation in South Africa, they were thrown deep into the weirdness of distributed work.

Our conversation started with a simple question: “How do you know if someone is actually working when you can’t see them ?”. Most in-office manager’s who are used to making the connection between seeing and believing, must be thinking this at some point.

I thought about it for a moment and realised that we do not think about new hires like this at Automattic.

New hires are given full trust. They get access to all the systems, all decisions for the past 15 years, all the user data their role requires and the full faith in their ability to do what’s required to move the business forward.

My very first remote manager, Michael Krapf, had a saying that went something like this: “A good trend means a good worker, and a bad trend means a bad worker”. You could interpret it as; we should not evaluate people on an instance by instance basis, but should rather keep in mind what they do over a period of time and evaluate that.

In a work setting, low trust relationships are normally created when people don’t do what they say they were going to do. This doesn’t mean that we expect someone to be perfect, it’s just means that there is an expectation of progress, and obstacles being communicate in a timely and transparent manner.

When you have a low trust relationship, you will have to shorten the feedback periods considerably. This evaluation period should be well understood by all involved. The aim here should be to grow trust, not to have continuous checkups that puts only one side of the relationship at ease.

When trust grows, so should the evaluation period. In fact, you should expect trust to grow so much that there is no evaluation period. This is the peak of trust, all involved respects each other so much that, no news is good news and transparent communication is the natural outflow of progress.

Trust is also the basis of collaboration and collaboration the basis of a forward moving team. So start with high trust and work forward from there.

Featured Image by Belinda Fewings on Unsplash

WooCommerce Payments now in Beta

I’m excited to share that our team has just released the beta version of a Payments service powered by WooCommerce, WooCommerce Payments.

Users of this gateway will be able to manage all payment related tasks, without leaving the the WooCommerce admin interface. We hope to roll out more features and support for more countries in the future, but for now we celebrate this milestone.

It was really great to join an amazing team as we wrapped up the final bits of this product, Kudos to all involved.

Now the real work begins and I’m excited to see the types of businesses that will benefit from this experience,

Take a look at all it can do for you here: https://woocommerce.com/payments/

The plugin is now available on the WordPress.org repository: https://wordpress.org/plugins/woocommerce-payments/