每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文，歡迎關注開源日報。交流QQ群：202790710；微博：https://weibo.com/openingsource；電報群 https://t.me/OpeningSourceOrg

今日推薦開源項目：《Docker docker_practice》傳送門：GitHub鏈接

推薦理由：Docker —— 從入門到……別擔心，這個並不會讓你入土。這個項目是一本 Docker 教學書，同時適合初心者和老手，如果想要學習 Docker 的話，這本書應該能成為不錯的資料。

今日推薦英文原文：《Developers, Truths and Myths.》作者：Marcus Low

原文鏈接：https://blog.usejournal.com/developers-truths-and-myths-9e7296c0c253

推薦理由：對於開發者的錯誤理解，雖然第四條大多數時候可能都是對的……

Developers, Truths and Myths.

I closed the project files for the last time on the WingIDE. I wrote my last code a year ago, when I was 44. Managing developers has taken up most of my time and giving up coding was a natural decision.

Contrary to popular belief, developers are not difficult to figure out and I』ve spent a huge chunk of my career on sorting, hiring, training, and motivating the good seeds. Developers also have loads of assumptions about the business world and the people within it, which I will try to address here in a bit. But first, some background about myself from when I first started off as a young developer with a devil-may-care attitude and courageous wit to beat.

I started developing when I was 14, wrote and sold my first commercial game in high school at 15 and nabbed my first job in Antivirus development after graduation. Throughout the tenure of my employment, I wrote one of the earlier macro virus real-time detection systems for Armour Antivirus, and a personal firewall for Norman Data Defense System, which then led to the start of my own company, InternetNow, at 27. Back then, there were hardly any companies offering internet solutions, less with the word 「Internet」 attached to their brand.

In 2006, I was invited to be a key speaker for a Jobstreet event and I spoke on the topic, 「Can I be a developer for life?」. The response was overwhelming with developers of all ages and skill packing the event space till there was hardly any leg room left.

Those days, the developer community in Malaysia was untapped and one of my important milestones was founding a local Python User Group with a fellow developer and coding enthusiast, Jeremy Johnson. At that point, I was predominantly developing on Windows so starting this community actually widened my exposure and reach to other ecosystems. I haven』t looked back since. I left my company in the hands of capable partners and joined a startup in 2015.

Now that you know more about me and can perhaps better relate to my torrential prose (I am after all not a writer, but a developer at heart), let』s take a look at some truths and myths about working with developers and the characteristics they tend to embody.

1. They can』t talk to humans, they can only communicate through computers

Mostly FALSE

This myth surfaced roughly during the 90s with the explosion of programming jobs for desktop Windows taking on nearly the entire market. Suddenly, companies were hiring teams consisting of self-taught programmers and IT graduates to help out on new hardware deployment, maintenance or applications development tasks. And to the more traditional hires, these new talents tend to be viewed as overtly quirky and a tad different in personality compared to everyone else. There is a reason for that.

Programming is a skill. Like any other skill, you have to spend time honing them. Google didn』t exist back then and neither did tools like StackOverflow or Github. Programmers had to learn everything by coding and experimenting on their own — there were no cut+paste type of 「developers」. The amount of time required to commit to these learnings meant sacrificing lots of socialising time and midnight teh-tarik (Malaysian version of coffee) sessions.

This lifestyle leads to a lack of EQ and difficulties in initiating conversations amongst non-developer crowds. Some may eventually warm up to it but others tend to remain socially awkward for a long time. Behind the keyboard, however, is a livelier story.

2. They hate salespeople

FALSE

Hate is a strong word, but let』s not digress. On a serious note, the fastest way to shut down a programming team is to put a salesperson in charge of running it. Specifically, a salesperson with a lack of domain knowledge can kill any team faster than you can type 「Hello World」

Overall, it has more to do with respect and respect has to be earned.

Scenario #1

A sales or marketing person (often it can be the owner / founder) walks to a team and says 「I need this in 3 months」 and will be honestly shocked when the dev team reports that such a project would require at least 6 months. Sometimes this gap becomes unbearable and a project manager is hired to conduct a detailed progress report and he/she would have to try very hard to explain why a project takes excruciatingly long to complete. This is often the job of the CTO, project manager or even product owner.

Scenario #2

A developer decides to create her own company and partnered with a friend in business development. When sales start picking up, the business development partner realises that it』s a lot of hard work selling their services; using her own car (chalking up high maintenance and petrol costs) and getting pinged at all hours by clients on technical issues. The partner then starts to demand more reimbursements from the company, foregoing the pre-set 「equal salary, 50–50 split」 expectations. The developer now feels she is being short-changed and these terms are no longer honorable.

Somewhere down the line, the partner figured out that she could find other products/services to re-sell and the partnership with the dev was no longer 「fair」 or necessary. It』s a situation of how salespeople tend to overrule tech. Happens more often than not.

Fact is, devs don』t hate salespeople but they don』t like to be jerked around with empty promises and by leaders with no technical knowledge whatsoever. Some companies value sales innovation over services innovation, a classic example would be how sales actually improved after Steve Jobs was evicted from Apple, but those figures didn』t end well without innovations. Startups on the other hand, need a lot more sales validation than idea generation.

3. Developers are difficult to retain

TRUE

Software developers, programmers, code writers, blockchain developers, full stack, backend, front end, the list goes on.

These are all various descriptions of the same role. A subpar developer will deliver mediocre codes at best but a good one will be able to pick up on new languages, platforms and generally code better even at a late start.

Tech jobs have been all the hype since tech companies entered the limelight and their shares have been skyrocketing faster than traditional companies. Hence, turnover is at an all time high.

If you want to keep quality developers, you only need to understand a few things.

a. Kill their boredom. Repetitive work and unchallenging tasks are what drives good developers away.

b. Hire a manager/VPE/CTO that understands coding and have some interest in the things that developers are passionate in. Developers often share common interests in games and movies so buzzwords like Counter strike, Dota2, League of Legends, The Matrix, Dark soul (hehe), are what team leads need to know in order to sync well with the team dynamics.

c. Flexible time and good resources breed the best developers. Force a 9–5 work schedule on them and you get a 9–5 product. Veteran developers do not buy into dream speeches or working with impossible deadlines. Good luck if you』re a startup with a shaky business model.

Flexibility is about trust. There are just three(3) types of developers in this scenario:

Those who enjoy this flexibility and would be productive in contributing.
Those who will abuse it by procrastinating and producing mediocre work.
Those who will use the extra time to moonlight.

Fire #2, coach and challenge #3 and reward #1.

4. Developers are destined to be single

FALSE

Some developers believe this is their fate. Remember how I mentioned that developers might have some issues making friends? It』s the same way, romantically. But in the 20th century, things have changed. If anything, being a developer is considered sexy — pays well and comes with a 「certified intelligent」 stamp — Intel Inside.

My advice is just be confident and most importantly, be yourself. I can testify to this, as I have a ring on my finger. Also, Sheldon Cooper, Leonard Hofstadter and Howard Wolowitz from 「Big Bang Theory」, all married, nuff said

5. Coding is not an age-friendly job

TRUE

At some point in time, it wouldn』t be. This is because you should have acquired enough experience and skill to guide the next generation in coding and architecture. This has nothing to do with intelligence, but given the nature of technology, new tools and services may require you to adopt knowledge quickly. Lesser energy and higher commitment that comes with age does not work to your advantage.

Look at typical 40-year-old developer, John and 28-year-old Amy.

John has to attend his kids』 rehearsals, occasionally ferrying his ageing parents to and from the hospital and helping out with chores at home. Weekends are packed with grocery shopping, house fixings and family time.

Amy, on the other hand, is thinking of which workshop to participate in, which event to socialise at, taking on interesting projects to boost her skills.

Which of these two will fare better in learning a new language or adopting a new technology, assuming they are both coding for the same task?

Here is the good news.

You can』t beat a team of developers led by a veteran lead who is willing to share, coach and guide the team.

Younger developers often see themselves as the 「striker」 in a football game. The problem is that everyone wants to be a star striker so when the game starts, you have a bunch of high energy, high potential players running towards the goal posts without a proper strategy. The game ends up with massive losses, lots of red and yellow cards flashed, and maybe some players in the hospital.

So if you are a developer with decades of experience, be a team lead, guide and coach instead of a coder, as that will contribute to the company significantly. Think VPE and CTO positions and spend your time learning up managerial skills, objectives and key results (OKRs), tracking measurements and pitching your technical experience to obtain projects, AWS/GCP credits and attract talents.

If you are the sole developer in your own company, it』s time to let go of those legos, share your wealth and trade for time.

Experience is gold, it allows you to avoid pitfalls or make a wise decision. I will close this point with a story for you to ponder upon.

Ages ago, when the priests and kings wanted to preserve the writings and commandments given to Moses, each new king was asked to make a copy for himself, then read and understand every word written. Anyone who copies the words considered them sacred and are careful not to add or remove any words that were passed down. With each generation, anyone with the possession of a new copy could compare and validate it to past versions. This prevents inaccurate duplications and deliberate 「additions」 to the original. So the 「oldest」 copy have no merit if the majority disagrees with it, this prevents age to be the variable of being 「original」.

Today, this ancient methodology is called BlockChain.

5 kinds of developers that you may want to avoid hiring.

1. The Shallows

These are sales guys passing off as developers. You can tell by the amount of GitHub projects they copied from other GitHubs or in recent trend, Kaggle clones. Their work shows a shallow technical capability that would impress non-techies and sometimes your bosses. In a team, he/she will usually be the one who enjoys steering communication towards non-essential discussions and often turns up at every event in the community to be in a crowd.

In a nutshell, these are people who insist on sticking to development without spending much time or effort on honing his/her craft.

2. The Entrepreneurs

These are developers who spend way too much time attending and winning hackathons, flaunting their status as an entrepreneur, CEO or some other hippy titles, yet with the skills and expertise that remains questionable. They may construct beautiful presentations and pitch decks, but falter when it comes to the actual execution.

After all, if you believe in your ideas that much, why will you waste time attending hackathons with a different idea each time.

3. The Rambos

Rambos are good developers with a decent set of skills and experience under their belt. They give off a vibe of competency and are often active in the tech community, open source projects and 101 other things. Sounds like a quality hire, right?

Here』s the issue. They often overcommit to various projects and consultations, being a jack of all trades and master of none. The lack of focus could be a problem, although there are a few gems of focused Rambos who will add significant value to any team.

4. The EMOs

There is this person who would always tweet/FB about how the world is against him/her. Every project request is torture and every feedback, a stab to the heart. While he/she can undoubtedly code, there is this certain element of negativity for everything that happens to them. Often this person will prefer and be asked to work solo.

I have always found such developers to be an enigma and highly undependable in any task.

5. The Perfectionists

「Follow this specific coding convention」. 「Use this exact implementation pattern」. The perfectionists are often 「by the book」 when it comes to codes. While it is near impossible to argue against the 「good」 that will come out of it, these perfectionists will spend way too much time getting things done, hence affecting overall delivery.

Almost like an artist, a perfectionist developer would rather starve and fail than deliver a product with a slight notch. While they are not exactly bad hires and will thrive in corporates or enterprises that need major cleanup assistance on existing codes, startups who require untested features to be validated may find these type of developers a nightmare to work with.

Finally.

HUXNNLALMRRCKFDYAKIH

H3NEAELAAOITUTRREMAO

TLDTTBMCLRODCENIEAOA

EAMNROTIOVVRIIANNHAA

TTTKIXACRR1HEMCANCNI

ANNA, there u go.

— cover photo is for illustration, photography is a popular hobby among developers 😉 ig : marcus_low

docker_practice

2018年10月2日：開源日報第208期