الان سال‌هاست که وارد عصر اینترنت شده‌ایم. ویژگی این عصر این است که به محص اینکه یک مسیر از کار و اقتصاد، بسیار سودده می‌شود، انبوهی از آدم‌ها به آن می‌ریزند. آنها که با جستجو در اینترنت و شبکه‌های اجتماعی، متوجه این مسیر جدید رسیدن به پول یا موفقیت شده‌اند، به زودی عرصه را بر هم تنگ می‌کنند.

آیا در این غوغا که یک دفعه هزاران نفر خود را کارشناس خبره یک کار جا می‌زنند، می‌توان باز هم موفق شد یا اینکه باید از این راه جدید، دل بکنیم و به وادی دیگری مهاجرت کنیم؟

حقیقت این است که این سال‌ها دست زیاد شده، اما آدم‌های ماهری که به صورت تخصصی و متمرکز در کاری مهارت داشته باشند، حتی از پیش هم کمتر شده‌اند.

مثال عرض می‌کنم: این سال‌ها تعداد آدم‌هایی که می‌گویند که متخصص بازاریابی، تولید محتوا، طراحی وب، ساخت اپلیکیشن و سئو هستند، خیلی زیاد شده.

اما وقتی شما عملا می‌خواهید کاری سطح بالایی سفارش بدهید، متوجه میشوید که اتفاقا در هر کدام از اینها آدم‌های متخصص بسیار کم هستند. در کمال شگفتی حتی تعداد آدم‌ها یا شرکت‌های کاربلد در برخی از این عرصه‌ها به تعداد انگشتان دو دست هم در یک حدوده جغرافیایی وسیع نمی‌رسد.

نتیجه: در کار خود ماهر و متخصص شوید، طوری که از بقیه کاملا متمایز شوید. روی یک مهارت تمرکز کنید و افق دید خود را گسترده کنید.

حتی در دریایی از آدم‌های با روزومه مشابه، این شما هستید که در نهایت توسط مشتری انتخاب خواهید شد!

منبع: “۱۳ پارادوکس عجیب و تفکربرانگیز زندگی مدرن ” از وب‌سایت یک‌پزشک

خیلی کم، اما گاهی پیش میاد که مطلبی یا ویدیویی یا مقاله ای که مخلوق دیگری است رو به اشتراک بگذارم تا دیگران ببینن.

هر بار که این کار رو انجام میدم باید به خودم گوشزد کنم که، هِی رفیق، فراموش نکن که قرار نیست چیزی از اعتبار خالق اون اثر با این عملِ به اشتراک گذاشتن، به تو برسه و نمیرسه. بنابراین یه وقت ژست خاصی نگیری!!

منبع: از نوشته‌های دوست عزیزم، مهدی مری در لینکدین

function makeAdder(x) {
  return function(y) {
    return x + y;
  };
}

var add5 = makeAdder(5);
var add10 = makeAdder(10);

console.log(add5(2));  // ?
console.log(add10(2)); // ?

I invited some of my friends to discuss the nebulous concepts of coupling and cohesion in software design. How do we think about these topics? How do we understand the terms? How do we use that in our work as programmers? How do we teach it to others? How much does any of it even matter? Our invited guests: Corey Haines, Curtis Cooley, Dale Emery, J. B. Rainsberger, Jim Weirich, Kent Beck, Nat Pryce, Ron Jeffries.

CSE Code-With Customer/Partner Engineering Playbook

An engineer working for a CSE project…

• Has responsibilities to their team – mentor, coach, and lead.
• Knows their playbook. Follows their playbook. Fixes their playbook if it is broken. If they find a better playbook, they copy it. If somebody could use your playbook, give them yours.
• Leads by example. Models the behaviors we desire both interpersonally and technically.
• Strives to understand how their work fits into a broader context and ensures the outcome.

This is our playbook. All contributions welcome! Please feel free to submit a pull request to get involved.

Note: If you are reading this on github – head over to https://microsoft.github.io/code-with-engineering-playbook/ for a better reading experience

Why Have A Playbook

• To increase overall efficiency for team members and the whole team in general.
• Reduce the number of mistakes and avoid common pitfalls.
• Strive to be a better engineer and learn from other people’s shared experience.

“The” Checklist

If you do nothing else follow the Engineering Fundamentals Checklist! It’s here to help follow the Engineering Fundamentals.

Structure of a Sprint

A breakdown of sections according to the structure of an Agile sprint.

General Guidance

• Keep the code quality bar high.
• Value quality and precision over ‘getting things done’.
• Work diligently on the one important thing.
• As a distributed team take time to share context via wiki, teams and backlog items.
• Make the simple thing work now. Build fewer features today, but ensure they work amazingly. Then add more features tomorrow.
• Avoid adding scope to a backlog item, instead add a new backlog item.
• Our goal is to ship incremental customer value.
• Keep backlog item details up to date to communicate the state of things with the rest of your team.
• Report product issues found and provide clear and repeatable engineering feedback!
• We all own our code and each one of us has an obligation to make all parts of the solution great.

QuickLinks

• Engineering Fundamentals Checklist
• Structure of a Sprint

Engineering Fundamentals

• Agile Development
• Automated Testing
• Code Reviews
• Continuous Delivery (CD)
• Continuous Integration (CI)
• Design Decision Logs
• Design Reviews
• Developer Experience
• Engineering Feedback
• Observability
• Security
• Source Control
• Reliability

Fundamentals for Specific Technology Areas

• Data and DataOps Fundamentals
• Machine Learning Fundamentals

Contributing

See CONTRIBUTING.md for contribution guidelines.