Di Lin's Blog

Terminology

• Rest: Representational State Transfer
• API: Application Programming Interface

RESTful API Main Criteria:

• Client-server

  A client-server architecture made up of clients, servers, and resources, with requests managed through HTTP.

• Stateless

  Stateless client-server communication, meaning no client information is stored between get requests and each request is separate and unconnected.

• Cache

  Cacheable data that streamlines client-server interactions.

• Uniform Interface

  A uniform interface between components so that information is transferred in a standard form.

  This requires that:

  • resources requested are identifiable and separate from the representations sent to the client.
  • resources can be manipulated by the client via the representation they receive because the representation contains enough information to do so.
  • self-descriptive messages returned to the client have enough information to describe how the client should process it.
  • hypertext/hypermedia is available, meaning that after accessing a resource the client should be able to use hyperlinks to find all other currently available actions they can take.

• Layered System

  A layered system that organizes each type of server (those responsible for security, load-balancing, etc.) involved the retrieval of requested information into hierarchies, invisible to the client.

• Code-on-demand (optional)

  The ability to send executable code from the server to the client when requested, extending client functionality.

Ref

• RedHat: What is a REST API?
• 理解本真的REST架构风格（转，解释的最清楚）
• Microsoft:
  • Best Practice for Cloud Application: Web API Design
  • Best Practice for Cloud Application: Web API Implementation
  • Microsoft REST API Guidelines
  • Asynchronous Request-Reply Pattern
  • Rest API Checklists

1. 练习盲打：https://www.keybr.com/

2. 程序员英语词汇宝典

3. 寒亭的学习笔记分享站

4. Youtube

5. Chandler Carruth | Speakers | Channel 9

6. Design Pattern:

   • 《Head First设计模式（中文版）》(O’Reiley)
   • 《Graphic Design Patterns 图说设计模式》

1. npm install fail with unknown reason.

   Try clean the cache before installation:

   1 2 3 4 5 6 7 8 9 10 11 12 13

   # Clean cache rm -rf node_modules rm package-lock.json npm cache clean -f # Install packages npm i # Check npm packages version npm outdated # Update pacakges npm update

The UML Class diagram is a graphical notation used to construct and visualize object oriented systems. A class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system’s:

• classes
• their attributes
• operations (or methods)
• and the relationships among objects.

UML Class Notation

A class represent a concept which encapsulates state (attributes) and behavior (operations). Each attribute has a type. Each operation has a signature. The class name is the only mandatory information.

Class Visibility

The +, - and # symbols before an attribute and operation name in a class denote the visibility of the attribute and operation.

• + denotes public attributes or operations
• - denotes private attributes or operations
• # denotes protected attributes or operations

Parameter Directionality

Each parameter in an operation (method) may be denoted as in, out or inout which specifies its direction with respect to the caller. This directionality is shown before the parameter name.

Perspectives of Class Diagram

The choice of perspective depends on how far along you are in the development process. During the formulation of a domain model, for example, you would seldom move past the conceptual perspective. Analysis models will typically feature a mix of conceptual and specification perspectives. Design model development will typically start with heavy emphasis on the specification perspective, and evolve into the implementation perspective.

A diagram can be interpreted from various perspectives:

• Conceptual: represents the concepts in the domain
• Specification: focus is on the interfaces of Abstract Data Type (ADTs) in the software
• Implementation: describes how classes will implement their interfaces

The perspective affects the amount of detail to be supplied and the kinds of relationships worth presenting. As we mentioned above, the class name is the only mandatory information.

Relationships between classes

类的关系有泛化(Generalization)、实现(Realization)、依赖(Dependency)和关联(Association)。其中关联又分为一般关联关系和聚合关系(Aggregation), 合成关系(Composition)。

虚线箭头指向依赖；
实线箭头指向关联；
虚线三角指向接口；
实线三角指向父类；
空心菱形能分离而独立存在，是聚合；
实心菱形精密关联不可分，是组合；

1. 泛化(generalization) ：表示 is-a 的关系，是对象之间耦合度最大的一种关系，子类继承父类的所有细节。直接使用语言中的继承表达。在类图中使用带三角箭头的实线表示，箭头从子类指向父类。

   

   • An abstract class name is shown in italics.

2. 实现(Realization):在类图中就是接口和实现的关系。在类图中使用带三角箭头的虚线表示，箭头从实现类指向接口。

   

3. 依赖(Dependency) ：对象之间最弱的一种关联方式，是临时性的关联。代码中一般指由局部变量、函数参数、返回值建立的对于其他对象的调用关系。一个类调用被依赖类中的某些方法而得以完成这个类的一些职责。在类图使用带箭头的虚线表示，箭头从使用类指向被依赖的类。

   
   

4. 关联(Association): 对象之间一种引用关系，比如客户类与订单类之间的关系。这种关系通常使用类的属性表达。关联又分为一般关联、聚合关联与组合关联。

   1. 一般关联。在类图使用带箭头的实线表示，箭头从使用类指向被关联的类。可以是单向和双向。

      
      

   2. 聚合(Aggregation) ：表示 has-a 的关系，是一种不稳定的包含关系。较强于一般关联,有整体与局部的关系,并且没有了整体,局部也可单独存在。如公司和员工的关系，公司包含员工，但如果公司倒闭，员工依然可以换公司。在类图使用空心的菱形表示，菱形从局部指向整体。

      

   3. 组合(Composition) ：表示 contains-a 的关系，是一种强烈的包含关系。组合类负责被组合类的生命周期。是一种更强的聚合关系。部分不能脱离整体存在。如公司和部门的关系，没有了公司，部门也不能存在了；调查问卷中问题和选项的关系；订单和订单选项的关系。在类图使用实心的菱形表示，菱形从局部指向整体。
      

      Cardinality is expressed in terms of:

      • one to one
      • one to many
      • many to many

      

      多重性(Multiplicity) : 通常在关联、聚合、组合中使用。就是代表有多少个关联对象存在。使用数字..星号（数字）表示。如下图，一个割接通知可以关联0个到N个故障单。
      

Relationship Discrimination

聚合和组合的区别

聚合关系是“has-a”关系，组合关系是“contains-a”关系；聚合关系表示整体与部分的关系比较弱，而组合比较强；聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。

依赖和关联的区别

• 依赖（Dependency）

  从字面理解的话，是说一个类用到了另一个类。这种使用关系是具有偶然性的、临时性的、非常弱的。比如下图中的依赖关系，司机开车，要依赖车。在代码上表现的话一般为函数参数，或者局部变量或者对静态方法的调用。注意依赖关系只能是单向的，并且依赖关系强调的是 使用上的关系。

• 关联（Association）

  • 关联关系强调的是一种结构上的关系
  • 他可以是单向的或者双向的
  • 从语义级别(上下文)可以分为聚合和组合，在代码实现上关联和聚合是很像的，主要区别在语义上
  • 一般来说双方关系是平等的，比如我和我的朋友
  • 在java语言上一般表现为全局变量。如person类和company类,顾客和地址,客户和订单

Example

Software to Draw UML Class Diagram

• Visio
• Enterprise Architect
• Rose

Ref

• UML Class Diagram Tutorial
• 最清晰易懂的UML类图与类的关系详解

NPM Dependency Management Model

Dependency Resolution

npm3 resolves dependencies differently than npm2.

While npm2 installs all dependencies in a nested way, npm3 tries to mitigate the deep trees and redundancy that such nesting causes. npm3 attempts this by installing some secondary dependencies (dependencies of dependencies) in a flat way, in the same directory as the primary dependency that requires it.

Imagine we have a module, A. A requires B.

Now, let’s create an application that requires module A.

Now, let’s say we want to require another module, C. C requires B, but at another version than A.

However, since B v1.0 is already a top-level dep, we cannot install B v2.0 as a top level dependency. npm v3 handles this by defaulting to npm v2 behavior and nesting the new, different, module B version dependency under the module that requires it – in this case, module C.

Noted that you can list the dependencies and still see their relationships using npm ls.

If you want to just see your primary dependencies, you can use:

1

npm ls --depth=0

Duplication and Deduping

See Duplication and Deduping article for better illustration.

Use npm dedupe to get rid of duplication.

1

npm dedupe

• Before dedupe

  

• After dedupe

  

Comparision with Other Package Management Models

At a high level, npm is not too dissimilar from other package managers for programming languages: packages depend on other packages, and they express those dependencies with version ranges. npm happens to use the semver versioning scheme to express those ranges, but the way it performs version resolution is mostly immaterial; what matters is that packages can depend on ranges rather than specific versions of packages.

Npm installs a tree of dependencies. That is, every package installed gets its own set of dependencies rather than forcing every package to share the same canonical set of packages.

For example, consider two packages, foo and bar. Each of them have their own set of dependencies, which can be represented as a tree:

1
2
3
4
5
6
7

foo
├── hello ^0.1.2
└── world ^1.0.7

bar
├── hello ^0.2.8
└── goodbye ^3.4.0

Most package managers (including RubyGems/Bundler, pip, and Cabal) would simply barf here, reporting a version conflict. This is because, in most package management models, only one version of any particular package can be installed at a time.

In contrast, npm has a somewhat easier job: it’s totally okay with installing different versions of the same package because each package gets its own set of dependencies. In the aforementioned example, the resulting directory structure would look something like this:

1
2
3
4
5
6
7
8
9

node_modules/
├── foo/
│   └── node_modules/
│       ├── hello/
│       └── world/
└── bar/
    └── node_modules/
        ├── hello/
        └── goodbye/

Pros

1. Extremely simple model but get pretty messy quickly.

   Notably,the directory structure very closely mirrors the actual dependency tree. The above diagram is something of a simplification: in practice, each transitive dependency would have its own node_modules directory and so on, but the directory structure can get pretty messy pretty quickly.

2. Avoid “Dependency Hell”.

   The npm model of package management is more complicated than that of other languages, but it provides a real advantage: implementation details are kept as implementation details. In other systems, it’s quite possible to find yourself in “dependency hell”, when you personally know that the version conflict reported by your package manager is not a real problem, but because the package system must pick a single canonical version, there’s no way to make progress without adjusting code in your dependencies. This is extremely frustrating.

Cons

1. Larger code size. Worse performance.

   Given the potential for many, many copies of the same package, all with different versions. An increase in code size can often mean more than just a larger program—it can have a significant impact on performance. Larger programs just don’t fit into CPU caches as easily, and merely having to page a program in and out can significantly slow things down. That’s mostly just a tradeoff, though, since you’re sacrificing performance, not program correctness.

2. Dependency isolation can affect cross-package communication.

   See this Dependency isolation and values that pass package boundaries section for detailed illustration.

   An failure example: Dialog will break if two version of botbuilder-dialog package exists

PeerDependency

PeerDependency: Rather than getting its own copy of a peer dependency, a package expects that dependency to be provided by its dependent.

The peerDependencies requires npm v7. For npm >= 3 and npm <= 6, peerDependencies can be declared but will not be automatically checked and installed.
That is to say, to leverage the peerDependencies feature, we will need to migrate to npm v7 as well as requiring user to update to npm v7.

• Node:

  • LTS: 14.16.0 (includes npm 6.14.11)
  • Current: 15.10.0 (includes npm 7.5.3)

Though node use npm v7 as the current version, the majority will be using npm v6 in 2021. Consider the population, asking user to update to npm v7 adds a new pre-requisite.

Ref

• Npm GitBook: Dependency Resolution
• Npm GitBook: Duplication and Deduping
• Understanding the npm dependency model

The Microsoft Authentication Library (MSAL) supports several authentication flows for use in different application scenarios.

Ref

• Authentication flows

Microsoft Identity Platform

The Basics

• The Authorization Server is the Microsoft identity platform and is responsible for ensuring the user’s identity, granting and revoking access to resources, and issuing tokens. The authorization server is also known as the identity provider - it securely handles anything to do with the user’s information, their access, and the trust relationships between parties in a flow.
• The Resource Owner is typically the end user. It’s the party that owns the data and has the power to allow clients to access that data or resource.
• The OAuth Client is your app, identified by its application ID. The OAuth client is usually the party that the end user interacts with, and it requests tokens from the authorization server. The client must be granted permission to access the resource by the resource owner.
• The Resource Server is where the resource or data resides. It trusts the Authorization Server to securely authenticate and authorize the OAuth Client, and uses Bearer access tokens to ensure that access to a resource can be granted.

App Registration

• An Application ID that uniquely identifies your app
• A Redirect URI (optional) that can be used to direct responses back to your app
• A few other scenario-specific values.

Endpoints

Once registered, the app communicates with the Microsoft identity platform by sending requests to the endpoint:

1
2

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

Tokens

// TOASK: How can bearer token ensure security in HTTP request? Can eavesdroppers get the header token?

• Access tokens - tokens that a resource server receives from a client, containing permissions the client has been granted.
• ID tokens - tokens that a client receives from the authorization server, used to sign in a user and get basic information about them.
• Refresh tokens - used by a client to get new access and ID tokens over time. These are opaque strings, and are only understandable by the authorization server.

Authorization Grant Types

Authorization Code Grant Flow

// TOASK: How does Web API validate token??

1. Request an authorization code.

   1 2 3 4 5 6 7 8 9 10 11

   // Line breaks for legibility only https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize? client_id=6731de76-14a6-49ae-97bc-6eba6914391e &response_type=code &redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F &response_mode=query &scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read%20api%3A%2F%2F &state=12345 &code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl &code_challenge_method=S256

2. Request an access token

   1 2 3 4 5 6 7 8 9 10 11 12 13

   // Line breaks for legibility only POST /{tenant}/oauth2/v2.0/token HTTP/1.1 Host: https://login.microsoftonline.com Content-Type: application/x-www-form-urlencoded client_id=6731de76-14a6-49ae-97bc-6eba6914391e &scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read &code=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq3n8b2JRLk4OxVXr... &redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F &grant_type=authorization_code &code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong &client_secret=JqQX2PNo9bpM0uEihUPzyrh // NOTE: Only required for web apps. This secret needs to be URL-Encoded.

3. Refresh the access token

   1 2 3 4 5 6 7 8 9 10 11

   // Line breaks for legibility only POST /{tenant}/oauth2/v2.0/token HTTP/1.1 Host: https://login.microsoftonline.com Content-Type: application/x-www-form-urlencoded client_id=6731de76-14a6-49ae-97bc-6eba6914391e &scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read &refresh_token=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq... &grant_type=refresh_token &client_secret=JqQX2PNo9bpM0uEihUPzyrh // NOTE: Only required for web apps. This secret needs to be URL-Encoded

Authorization Code Flow (with PKCE) for SPA

// TOASK: Is it secure to use auth code in SPA when using PKCE?

Implicit Grant Flow

• Note: With the plans for third party cookies to be removed from browsers, the implicit grant flow is no longer a suitable authentication method. authorization code flow is recommended for all new applications including SPAs.

Resource Owner Password Credentials

Client Credentials

Example

In our implementation, Tab app uses authorization code flow with PKCE.

1. Tab App frontend gets auth code.
   1. Frontend browser pop up login page (/public/auth-start.html).
   2. User login and consent, frontend page redirect user to redirect_uri (/public/auth-end.html).
   3. End page parse authorization code and return to tab app.
2. Tab App sends the auth code to backend auth server to get access token.

More Read

• OAuth 2.0 Introduction

Ref

• OAuth 2.0 and OpenID Connect protocols on the Microsoft identity platform
• Scenario: Single-page application
• Microsoft identity platform and OAuth 2.0 authorization code flow

The format of a formal email in English

From / to / cc / bcc

Subject

Remember to have a concise and eye-catching subject so your email won’t get missed. DON’T send an email without a subject.

Greeting

• For the Germans and the English, use Dear xxx
• For the Americans, use Hi and Hello directly.
  • Hi Bob,
  • Hi team,

Body

• Introduction
• Body of the text
• Conclusion

Closing

• Thanks, / thank you,

  More casual and friendly in tone. Used when you’re asking for something.

• Regards, / Best regards,

  More professional. Better to use when close an informational note.

• Yours,

• Sincerely, / Yours sincerely,

• best,

• take care,

• cheers,

• talk soon,

Signature

Di Lin,
MetaOS team, DevDiv China

Useful Abbreviation

• ASAP: As soon as possible
• FYI: For your information
• OOF: Out-of-office
• WFH: Work from home
• TL’DR: Too long, don’t read
• LGTM: Look good to me
• TBD: To be done, to be decided

Example

Subject: vscode-iot-workbench v0.1.15 has been released

Hi team,

The latest vscode-iot-workbench v0.1.15 has just been released with all tests passed. For more details please see xxx. Thanks!

Regards,

Di Lin,
MetaOS team, DevDiv China

Email Samples on Different Topics

Discussion

• Please see my comment in line.

• When other team member raise another suggestion or solution you disagree, instead of arguing he’s wrong, you can try to agree on his solution first with sincere example. Then raise your solution, talk about the difference between them and come out with a conclusion with category.

  We agree that xxx is a good choice / idea when xxx. And it is perfect to do xxx. For example, xxx. This will xxx and will be a good choice.
  But for this scenario xxx, it is more clean to just do xxx.
  So to summerize, we would like to separate the two scenarios: 1. xxx. 2. xxx.

• During discussion email thread process, remember to occassionly thank the people discussing with you. This can ease the discussion tense and remind people that you are discussing to improve the product and not mean to aim anyone.

  Thanks @people for lots of suggestions, especially the xxx. The suggestion really helps to understand and re-think more about the design of xxx.

• Need more info.

  Thanks for the suggestions. Can you share more about the thoughts behind following ideas? Knowing the improvements we want to achieve with the ideas would be very helpful for us on detailed design. I also attached some technical details that may bring impact to the expected improvements.

• Do you want to collect all the concerns and open issues, and then we can schedule a meeting to resolve them?

• You mentioned other architectural concerns. Let’s get them on the table. Have you written them down somewhere? Happy to review.

• On the flip side, sharing credentials is considered an anti-pattern.

• Share the current status of your process. What your team has decided and been working on.

  To summarize current status: the xxx idea is great and we agree that we do sth. We’re actively working on the SDK design, and will share more details with sample code in next review meeting.

  Thanks for the feedback and I’d like to share our updates and ideas to discuss.
  Updated items:

    1.   
    2.  
  

  Need further discussion:

    1.   
    2.  
  

• Ask other team for technical advice.

  There’re some technical considerations and best practices that impacts our design. For example, xxx. This impacts the design of xxx. In the meanwhile, the existing xxx also follows similar practices. I’m not able to share all the considerations in the thread and apologize for the confusions caused.

• Greet new member join to discuss.

  Hi xxx, Glad to talk with you. To provide some background, we’re working on the xxx.
  I recommend we sit down with Bob who is the architect of xxx. I’ll brief him on the situation tomorrow and then set up a call with him so we can get the right design.
  Thank you very much, Alan. Looking forward to talk with you and Bob.

• Sync the release plan with other team. Call out if there is any concern so you don’t get blocked by other team.

  Can you share the release plan of the xxx support? That would be very helpful to our planning. And for the coding experience, we currently would like to have xxx (techinical details). If you have the same scenario implementation, please also share with us.

• Can you please articulate(明确说明) why specifically the xxx interface is not suitable for an xxx flow?
  Can you please articulate the release plans for the xxx, and point us to the design doc and/or code in progress if possible?

• Please have a look at the docs and feel free to let us know if further meeting needed or we could close it offline.

• I left a couple of additional comments for thought. I think we are really close now.

Project Trantision

When you are on a product transition process with other team, communication counts. This process usually includes cross-team communication and it is vital for your career reputation.

Farewell

Dear friends and colleagues,

As some of you know, I’m going to move on to a different role outside of <company-name>, and my last day is Friday, August 30th. I’m a fan of <company-name> since I was 22 years old, and enjoying my job here after joined in <company-name> 5 years ago. So this is really a hard decision to me in this summer, I think the decision is in the best choice of my career goals and personal interesting, or it’s called ‘follow my heart’.

5-years is not a short period in a person’s life, but how lucky I am is joining this team and working with you guys! It’s really an incredible wonderful journey in my life! Learn and grow, enjoy everything here, and make a lot of good friends. So thank you everyone, it’s been so great working with you!

It’s no goodbye but see you around, keep in touch!

Sincerely,
xxx

Hi,

Today is my last day working in <department-name>. I will soon start another role in <another-department-name>, to continue to explore the IoT territory.

It was still vivid to me the days and nights, smiles and tears we have been working on the <project-A>, <project-B>, <project-C> and all the products. Also I witness the growth of <department-name> that now we have multiple charts there. I was so thrilled to be part of this team. Thanks to all of you!

Specially thanks to Bob my manager, who provided numerous helps and guides to me during the past 3.5 years, to shape me up as a good PM for the domain I worked. I learned a lot from you and pretty sure it will benefit for my next endeavor.

I am still in the xxx domain, and we will also have lots of cross paths and collaborations in the near future. Looking forward to it.

Thanks,
xxx

Dear all,

As some of you may know, I am leaving <company-name> and today is my last working day.
I started my career in <company-name> back from Mar 2010 and it is 10 years already. It is still vivid to me all the days and nights, smiles and tears we have gone through along the way, from <project-A> to <project-B>. I felt so lucky when getting offer from <company-name> in 2009, and I still feel the same today.

Special thanks to my manager Alen and all SLTs, who give me all the opportunities in <department-name>, support me for the various decisions we have made, and encourage me to try something new. I’d like to say thank you to our PM team, especially Bob as well. We know each other for long time and started working together for several years. I really enjoy working with you and your team on various projects over the years. And thanks to all precious managers: Andrew, Eric, Tom and Mike. I cannot achieve so much without your help and guidance.

I also want to say THANK YOU to all my current & previous colleagues, and partner teams. It is a great journey working with you over the years. It’s the lifetime memory to me.

Mobile and Wechat: xxxxxxxxxxx
Personal mail: xxx@outlook.com
Linkedin: https://www.linkedin.com/in/xxx/

xxx
<department-name>

Hi friends,

Some of you may already know that I’ll explore new adventures outside <company-name> from next week. Today is my last day at <company-name>.

I joined <company-name> after graduation in 2016. It’s my pleasure to start my career path from such a big company with many creative products. It’s also my fortune to work with so many talented teams and guys. Thanks Bob and <department-name> leadership team for giving me opportunity to work and improve myself in this comfortable environment.

Special thanks to my manager Alen, who gave me a lot of help and guidance in my career development, which will equip me for whole career. A role model can help me lay out a career path that is realistic and practical. I believe my future career will benefit a lot from you.

Also thanks for my mentor A, B and C. We’ve been working on different projects, I learnt a lot from you about how to face the challenges and strengthen talent.

To my buddies in <project-A>(as well as PM team), <project-B>, <project-C>, it’s nice working with you. Thanks for great moment we spent during and off work.

Thanks <teammate-A> for innovation and interesting ideas in all kinds of projects. Really enjoy the creative projects we worked together in IoT area.

In the future, you can reach me via +86xxxxxxxxxxx (Wechat with same mobile). Let’s keep in touch.

With best kind regards!

xxx

Congratulations

• Congratulations!
• Congratulations to you!
• Congrats to you!

Ask for Feedback

Hey Di,

The transition of IoT extensions is mainly completed. Would you please share your feedback with me about the collaboration, communication, management, etc.? I really appreciate your thoughts which are helpful to make me better in future projects :)

Yan

Ref

• How to Write Formal Emails in English`

Work Methodology is hard to change since we have inertia. Practice more to change it!

Presentation (Demo / Tech Sharing)

How to do presentation or tech sharing effectively?

1. Who is your audience and what do they want to hear / what can they take away? Construct your meterial from the stakeholders’ angle. Learn what your audience is doing.
2. Ask experts for what they recommend.
3. If you are doing a MVP demo, it is vital to get feedback cause that’s your main goal. Through demo, you can gather more points of view so you can improve your product at an early stage.
4. Rehearsal before presentation.

Turn Bad Porject to Shining Gold

The most vital thing is not how important or hard your task is. Of course good project means you have more resources. But if it happens that your project sucks, it is how you can do it perfectly that matters. Shine it by:

1. Do it well.
2. Communicate well between teams. Increase the across-team impact.
3. Empower other teams by your “little” and “trivial” project.

Think More

DO NOT only finish the task you are told to do. That’s just the basis.Take a second to think more:

1. Which part do I miss?
2. Ask experts for feedback that can improve your methodology and remind you aspects that you miss for your lack of industry experience.
3. Focus on the “WHY” part of your task. Does it make sense to do thing this way? Can we improve it?

Do Things THOROUGHLY

1. After your task is done, you can intiatively do a demonstration inside or outside the team. It is a good chance to gather feedback for your product and expand your impact.

2. Re-think the WHY part of the project. Can I improve anyhing?

3. How do I finish this task? Score yourself for the performance. What can I learn through this task?

4. Summerization and sharing.

5. Take an example, if you write a tool for your team, you can do the below thing to make this task complete:

   • Place the code in a correct and complant place where other team member can easily leverage it. (eg. Azure DevOps of big team’s org)
   • during development, keep stakeholders aware of the latest progress and your future action items. This can also remind them that you are contributing.
   • Write README file or tutorial / wiki for your tool so later when the project is transferred it can be easy to use.
   • Do demo.
   • Write project summary for it to remind all the pits you encountered.

Focus on the WHY part

Your boss literally does not care how technically hard your task is, it is the value of the task that he cares. Have a clear mind why your team is asking you to do the job you are currently work on. From your bos’s angle, what is the urgent problem he would like to resolve? Can you help with that?

Grow Sense of Ownership

Develop your ownership. Initiatively drive meetings / discussions over your project. Think more of your project. Your project is where you build your own career reputation.

Cross-team Communication

1. Drive the process. Don’t be passively pushed forward. You got to take the initiative.
2. Mind not to distractive readers in email thread. Construct your email logically and mind the subtle details. Or it might have bad effect on your boss who is not very familiar with the truth.
3. Effective communication.

Be Expert of What You Are Doing

Don’t just finish your task. Dig into the details of what you are doing. You got to be very familiar with the detailed implementation and all the subtle corner cases because that ensures your task quality.

Tips for Career

1. Gather feedback or compliment each time you co-work with others, especially cross-team. You can email the people describing the entire process and your thankness. Ask them to give you some feedback to help you grow.