Team work (1)

  • First , lets see where are we ?
    Lets stop arguing what is the best practice and focus on moving forward . if what we are not moving forward everyday , we will be lost in some day.

  • Second , gap ? we need alignment !
    Where is the next stop ? and how does it comes up ?it comes up from a lunch time discussion ? or it is coming after a details planing ? Lets stop for a moment and think about it .
  • Everyone have a voice on a solution ? who will be the one make decision.
    In a start up , this is happening quite often. again , the important thing is not who is right or wrong , or even best . lets apply one by one and try it again and again and again!
  • Coding style ? yes , we need it . but not about any one , about team .
    This is about every team . everyone may has a different opinion on the codes they are writing . but , what is more important ?
    testable ?readability ? maintenance ? performance ? or extensible ?
    – you jumped into a project in the middle , just follow the coding convention the team is coding . (DON’T)you will do a interface for anything you dislike ?
    – you are starting a new project . remember:
    — spending too much time on design but forgot prototype
    — over engineering .thinking too much on which technology to use to do the job (get it done first!)
    — take into everything into account ? forget about it ! now create a project and put some code get it work .moving forward!
    — coding or patterns or practice is really depends on the team skill set , after everyone agree on the (not so bad) naming convention, just start. any part you dislike such as moving method into new class , a visitor or command pattern, just do refactoring job on your own. but don’t expect others will do same as you did .
    — but like DI , stairway pattern , or layers or micro-service , should be clarify in the first time.
  • We have to rush on a ticket? This is the steps i will think of
    1. finish the feature ,if possible , write unit test after each single step.
    2. go through the logic and add comment where necessary .
    3. got time to refactor ?
    — clean up dependency by DI
    — analysis where need to have an interface .
    — behavior and data keep separate .
    — inheritance ? careful . in real world , inheritance is natural .but in programming , inheritance usually come to picture after composition.
  • Attitude , yes, most important come last
    you are software engineer , not a potter or pantry auntie ! so you have to get things done right ! be responsible what we write. no time is not an excuse , keep in mind : Unit Test during development , system monitoring during maintenance ! find and use new tools to automation the job ! again , you are programmer ! (not a coding monkey)
    watch team steps , what is stopping us from moving forward, point it out!
    watch yourself , don’t be the one dragging team behind

Author: lanliang


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s