How to be awesome

From CitconWiki
Revision as of 12:32, 22 September 2014 by Anhngoc.phung (talk | contribs) (Created page with " ==== HOW TO BE AWESOME ==== how to be attractive, how to be better share how to have software that nobody have to deploy…????? how not to fix bug, not have bug at all? ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

HOW TO BE AWESOME

how to be attractive, how to be better share how to have software that nobody have to deploy…?????

how not to fix bug, not have bug at all? how to keep the company small, like e.g instagrams: 13 employees, no legaxy code, or DRW

new code is better, or not.

i understand better, after i rewrite the code, or not

good company should not happen

great college,

joininc: as joyfull as possible, mean that employee they feel all good

see more at Osper Technology Blog

One Bug/month

There are two keys

= focus on test: take long time to go, write test slower, but good: take your time, test your environment carefully make huge investment in test, (cloud service: 100 phy. Server, alot of VMs) 200k Test weekly. (a lot of bug discover)

= Using pair programming in the team.

(Tim Group do it every day)

no one is single point of failure anymore.

take a little bit time at the beginning, bug save a lot of time of fixing bug.

writing test takes longer than writing code

the same person who writes the test is the one who writes the code.


No legacy code

legacy code is the social

i have a lot of legacy code? ==> my team to day an me we do not understand the code, and won’t change it. But if i should rewrite them, piece by piece and 6 months later => now i know this code is legacy.


how to do this?

now i understand more that the legacy code, (rewrite code to understand better)

it’s difficult to rewrite code in the small of piece of code.

build your architecture that simple to you, maybe could have legacy code but should be killed everytime if you’d like

how to recognize legacy code: during write of code, you can not recognize it => pair programming should help

"If you write it crappy, keep it small „ => MLADE


TINY TEAM

Tummblr: Instagramm 13 Employers

make sure code is small, deployment automatically

the cheaping: simple as possible, office shell software

build third party software:

travaol

== in App help == automate help, automate answer. They do not have phone number to be called


JOYFUL WORK

== hard to make sure that the company is joyful. (joyinc)

you need people in your organisation to say: this is important for us!!!

need some one to make that influence to the whole company

=> every one should have freedom, the but facter.

every one should have some one in backup, so that they can have free time, or they should take free time.

"bring the baby to work“ Policy

==> should make the employee happy.

joyful work is not meaning that everybody is happy all the time. but it should work great.