TRUNGTQ

Think Big, Act Small, Fail Fast and Learn Rapidly

NAVIGATION - SEARCH

Benjamin Franklin thành công nhờ việc hôm nay không để ngày mai

 
 
Ông luôn tụ răn mình " Việc hôm nay chớ để ngày mai"

Benjamin Franklin là người nổi tiếng về sự ham hiểu biết của ông, bậc vỹ nhân đầu tiên của nước Mỹ từng chia sẻ: Thành công mà ông đạt được, không nhờ gì khác ngoài nghị lực phi thường và sự bền bỉ quyết tâm theo đến cùng.

Sau khi xem kỹ danh sách dài những thành tựu của Benjamin Franklin, người ta chỉ có thể rút ra một kết luận: Người đàn ông Mỹ này trong thời kỳ Phục Hưng có lẽ không có đến một ngày ngồi không trong suốt cuộc đời. Trong suốt 84 năm cuộc đời, ông đã nổi bật với nhiều vai trò khác nhau: một tác giả, thợ in, chính trị gia, giám đốc sở bưu điện, nhà thơ trào phúng, nhà đầu tư, nhạc sỹ và nhà ngoại giao. 

Những bài học thành công trong cuộc sống từ chính kinh nghiệm của ông được đúc kết lại, và truyền đạt là một bài học quý cho những thế hệ sau học tập và noi theo.

Người khôn ngoan là người "Nói ít - Nói đúng"

“Nói càng nhiều sẽ càng tạo nhầm lẫm - He that speaks much, is much mistake.”

Ông dạy rằng nên đắn đo lời nói, chỉ nên nói những điều cần thiết. Khi bản thân nói ít, bạn sẽ làm chủ được lời nói của mình, tránh được những hiểu lầm, sai lệch không đáng có. Biết điều tiết lời nói, hạn chế nói thừa thải, bạn sẽ tạo được sự chú ý và lòng tin cho người đối diện.

Giá trị lớn lao của lao động

 “Người lao động là người hạnh phúc. Người nhàn rỗi mới là người khốn khổ - It is the working man who is the happy man. It is the idle man who is the miserable man.”

Lời khuyên này chỉ ra giá trị của sự cần cù và bền bĩ trong lao động. Benjamin nhấn mạnh rằng muốn tồn tại, muốn hạnh phúc thì bạn phải biết lao động. Chính lao động làm cho con người giỏi giang hơn, hoàn thiện hơn. Mỗi suy nghĩ nhàn rỗi, ỷ lại, lười biếng đều chỉ con đường đi gần hơn với sự khốn khổ, nghèo đói trong cả tư duy lẫn vật chất.

Thiên tài cũng cần phải học

“Thiên tài mà không trau dồi kiến thức cũng giống như bạc trong mỏ - Genius without education is like silver in the mine.”

Franklin nổi tiếng là người ham hiểu biết và luôn tìm tòi đa dạng hơn các lĩnh vực mà ông quan tâm. Ông nhấn mạnh điều kiện tiên quyết dẫn đến mọi thành công chính là nỗ lực cá nhân và giá trị của lao động. Ở nhiều người, chính sự hài hoà của tài năng bẩm sinh, cộng với nổ lực từ chính bản thân mới giúp các thiên tài thăng hoa, đưa họ tới đỉnh cao trong lĩnh vực theo đuổi.

Đầu tư vào tri thức là đầu tư khôn ngoan nhất

“Nếu một người đổ hết ví vào đầu, sẽ không ai cướp nó khỏi anh ta - If a man empties his purse into his head, no one can take it from him.”

Đây là một trong những phát ngôn sâu sắc nhất của ông. Thông điệp được ông truyền tải rất rõ ràng: nền tảng của sự thịnh vượng, giàu có không gì ngoài “Tri Thức”. Hầu như tất cả những người thành công trên tất cả lĩnh vực chính là minh chứng sống cho câu nói trên – Hãy đầu tư cho chính bản thân bạn! 

Dũng cảm thừa nhận sai lầm!

“Có rất ít người đủ can đảm để thừa nhận sai lầm của chính mình, hay đủ quyết tâm để sửa chửa chúng – How few there are who have courage enough to own their faults, or resolution enough to mend them”

Cảm giác sợ hãi luôn là kẻ thù giấu mặt khiến bạn nép mình trong vùng an toàn của bạn thân, tìm mọi cách lấp liếm khuyết điểm của chính mình. Đây là cốt lõi hạn chế đưa bạn đến con đường thành công. Hãy nghiền nát nỗi sợ và học hỏi mọi đều bạn muốn.

Đừng lo lắng khi mắc sai lầm, Bạn có thể nếm mùi thất bại, nhưng điều quan trọng hơn là tiếp tục vượt qua chúng.

Hành trình “phủ sóng” khắp thế giới của Uber

Năm 2009, một công ty có tên UberCab đã khiến cả thung lũng Silicon sửng sốt với dịch vụ đặt xe qua điện thoại thông minh...

Hành trình “phủ sóng” khắp thế giới của Uber

CEO Uber, ông Travis Kalanick - Ảnh: Reuters.

Năm 2009, một công ty có tên UberCab đã khiến cả thung lũng Silicon sửng sốt với dịch vụ đặt xe qua điện thoại thông minh, theo Business Insider. Sau này đổi tiên thành Uber, ứng dụng này đang “phủ sóng” tại 570 thành phố trên thế giới và có giá trị ước tính khoảng 70 tỷ USD.

Liên tục hút vốn

Sau hội nghị công nghệ LeWeb năm 2008, Kalanick nảy ra ý tưởng đặt xe giá rẻ bằng điện thoại và cho ra mắt Uber vào năm 2009. Garrett Camp, Oscar Salazar, và Conrad Whelan là những người xây dựng phiên bản ứng dụng đầu tiên, còn Kalanick đóng vai trò “siêu cố vấn”.

Năm 2010, Uber ra mắt ở San Francisco. Thời điểm đó, mức phí của Uber cao gấp 1,5 lần taxi thông thường nhưng ưu điểm là hành khách có thể đặt xe chỉ bằng một nút bấm. Ứng dụng này nhanh chóng trở thành cơn sốt tại thung lũng Silicon. Và cũng vì thế, Travis Kalanick nổi lên như một ngôi sao trên bầu trời công nghệ.

Tháng 10/2009, Uber nhận 1,25 triệu USD đầu tư từ quỹ First Round Capital, Chris Sacca (bạn của Kalanick) và nhà đồng sáng lập Napster, Shawn Fanning.

Đến đầu năm 2011, ứng dụng này nhận 11 triệu USD sau vòng gọi vốn Series A, động thái giúp giá trị công ty tăng lên 60 triệu USD. Tháng 5 năm đó, Uber tiếp tục ra mắt tại New York, một trong những thị trường lớn và gây tranh cãi nhiều nhất. Từ tháng 12 năm đó, ứng dụng này lấn sân sang Paris (Pháp) đồng thời nhận thêm 32 triệu USD sau vòng gọi vốn Series B.

Giữa 2013, Uber mở rộng sang Ấn Độ và châu Phi, nhận thêm 258 triệu USD sau vòng gọi vốn Series C từ Google Ventures, giúp nâng giá trị công ty lên 3,76 tỷ USD.

Tháng 7/2014, Uber đặt chân sang thị trường Trung Quốc sau khi huy động được 1,2 tỷ USD, nâng giá trị lên 17 tỷ USD. Cuối năm đó, ứng dụng này tiếp tục nhận 600 triệu USD đầu tư từ hãng tìm kiếm Trung Quốc Baidu. Uber bắt đầu tích hợp ứng dụng bản đồ và tìm kiếm qua di động của Baidu, “khai chiến” với các hãng công nghệ lớn của Trung Quốc.

Tháng 9/2015, Uber tiếp tục huy động được 1,2 tỷ USD để mở rộng hoạt động tại thị trường Trung Quốc với đối thủ lớn nhất là Didi Kuaidi.

Dịch vụ “phủ sóng” ngành vận tải


Tháng 7/2012, Uber tiết lộ dự án bí mật “Uber X” giá rẻ với giá dịch vụ thấp hơn 35% so với dịch vụ xe xa xỉ “UberBlack” trước đó và sử dụng các dòng xe như Prius và Cadillac Escalade. Kalanick khẳng định: “Uber là sự giao thoa giữa vận tải và phong cách sống”.

Tháng 4/2014, Uber ra mắt dịch vụ giao hàng UberRUSH tại Manhattan và bắt đầu mở rộng sang thị trường Trung Quốc từ giữa năm này. Theo Business Insider, quốc gia đông dân nhất thế giới là một trong những thị trường lớn nhất của Uber.

Giữa năm đó, Uber hợp tác với Blade cung cấp dịch vụ di chuyển bằng trực thăng UberCHOPPER từ New York đi Hamptons với giá 3.000 USD/lượt. Đồng thời, dịch vụ UberPool cho phép ngắt chuyến và chia tiền phí giữa hành khách có cùng lộ trình, cũng ra mắt.

Đầu 2015, dịch vụ UberCARGO ra mắt ở Hồng Kông, giúp Uber phủ kín tất cả các dịch vụ vận chuyển và đi lại. Uber gọi dịch vụ này là phương thức “vận chuyển hàng hóa như một VIP”.

Tháng 3 năm đó, hãng này bắt đầu tiến trình mua lại ứng dụng bản đồ deCarta nhằm giảm phụ thuộc vào Google Maps. Tiếp đó, dịch vụ chuyển đồ ăn theo yêu cầu UberEATS ra đời, thí điểm tại 4 thành phố: Los Angeles, Barcelona, Chicago và New York.

Tháng 5/2015, Uber tuyển dụng 40 nhân viên từ đại học công nghệ và máy tính hàng đầu của Mỹ Carnegie Mellon để phục vụ cho dự án chế tạo xe tự lái.

Tiếp đó, Uber ra mắt dịch vụ xe tự lái đầu tiên tại Pittsburgh với dòng xe Ford Fusion được trang bị 20 camera, 7 máy laser, định vị GPS, hệ thống Lidar và thiết bị radar cho phép tạo bản đồ 3 chiều sử dụng các địa danh và nhiều thông tin địa điểm khác để theo dõi vị trí.

Tuy nhiên, không lâu sau đó, cơ quan quản lý xe cơ giới California đã thu hồi 16 xe tự lái thử nghiệm của Uber và buộc dừng hoạt động này tại bang. Sau đó Uber chuyển chương trình sang Arizona.

Năm 2016, Uber tiếp tục hợp tác với Airbus cung cấp dịch vụ UberCoper, thử nghiệm trong một tháng. Dịch vụ trực thăng này có giá 63 USD hoạt động tại thành phố Sao Paulo vốn nổi tiếng với tình trạng tắc nghẽn giao thông.

Trong đà tăng trưởng nhanh và mạnh mẽ, từ đầu năm 2017, Uber liên tiếp vướng vào nhiều vụ bê bối, tuy nhiên điều đó không tác động nhiều tới việc kinh doanh của hãng.

NativeScript là gì?

http://docs.nativescript.org/

Công cụ phát triển NativeScript sử dụng JavaScript và Typescript để xây dựng các ứng dụng gốc cho iOS, Android, và Windows Phone.

NativeScript, một công nghệ của công ty Telerik dành cho việc xây dựng các ứng di động gốc đa nền tảng từ một code duy nhất, và đã sẵn sàng để phát hành phiên bản 1.0 vào cuối tháng Tư. Telerik đang giới thiệu chương trình dùng thử vào tuần này dành cho mã nguồn mở NativeScript.

Trang web của NativeScripttrang GitHub mô tả thời gian chạy cho phép các lập trình viên sử dụng JavaScript và TypeScript để xây dựng các ứng dụng gốc cho iOS, Android, và Windows Phone (qua chiến lược Windows Universal) và chia sẻ code khắp các nền tảng. "Các lập trình viên có các kỹ năng về Web muốn xây dựng các ứng dụng gốc đích thực nên cảm thấy hứng thú bởi vì bây giờ có một cách giúp họ thực hiện được việc này" mà không cần có sự am hiểu về các ngôn ngữ quen thuộc hay các framework, ông Todd Anglin - phó chủ tịch của Telerik cho biết.

NativeScript sản xuất các ứng dụng mà có UI gốc, ông Anglin nói. "Đó là ứng dụng không render HTML trong một Web view - như với các ứng dụng lai (hybrid app) hay các ứng dụng trình duyệt truyền thống.... NativeScript cho phép ưu tiên các công cụ JavaScript trên iOS, Android, và Windows để điều khiển UI layer gốc."

Các lập trình viên sử dụng các library của NativeScript, mà tách ra các sự khác biệt giữa các nền tảng gốc; các lập trình viên cũng sử dụng CSS và ECMAScript 5. Node.js cho phép các nhà phát triển ứng dụng chỉ cần sử dụng Javascript để lập trình cho server-side "sắp xếp vai trò (helps) mà JavaScript cung cấp cho ứng dụng di động," ông Anglin cho biết.

NativeScript cung cấp sự truy cập đầy đủ vào nền tảng gốc API, và nó đặc trưng máy ảo JavaScript đã đóng gói trước; JavaScript được viết cho ứng dụng NativeScript vẫn chạy như JavaScript trên một thiết bị. "NativeScript sẽ thi hành JavaScript này trên các máy ảo JavaScript gốc được cung cấp bởi iOS (JavaScriptCore), Android (V8), và Windows (Chakra)," ông Anglin cho biết. NativeScript cung cấp "một proxy của JavaScript hiện ra tất cả các API của iOS/Android/Windows vào các máy JavaScript này, bằng cách đưa quyền điều khiển đầy đủ cho JavaScript để điều khiển các khả năng của thiết bị gốc."

NativeScript cũng xử lý UI gốc đa nền tảng, cung cấp ngôn ngữ đánh dấu siêu văn bản bằng thẻ (Markup language) được phân tách vào các công cụ UI đặc trưng nền tảng khi một ứng dụng được xây dựng. "Ví dụ như: khi một lập trình viên thêm một nút vào một ứng dụng, thì NativeScript sẽ tự động sử dụng nút điều khiển UI gốc thích hợp từ iOS, Android và Windows."

Anglin thấy rằng NativeScript khác với các công nghệ phát triển di động khác, chẳng hạn như Appcelerator Titanium, công nghệ này cũng có ý nghĩa là cho phép xây dựng các ứng dụng di động gốc qua JavaScript. Anglin dám chắc rằng Titanium có quá nhiều sự tùy biến, làm nó mang tính cá nhân nhiều hơn.

"Sự khác biệt lớn giữa một ứng dụng NativeScript và một ứng dụng lai (chẳng hạn như PhoneGap hay Sencha) là NativeScript không phụ thuộc vào trình duyệt/Web UI layer để render ứng dụng. Nó render một UI gốc, không phụ thuộc trình duyệt....Trình duyệt hay Web UI layer đó thường có sự bế tắc trong các ứng dụng di động mà muốn có các hình ảnh động đẹp và scrolling."

Telerik đã thông báo về NativeScript vào cuối tháng Sáu, công ty hy vọng tiền tệ hóa (monetize) NativeScript bằng việc đưa ra các công cụ nền tảng và UI cao cấp.

LINK: http://www.itjobs.com.vn/vi/article/javascript-trong-cac-ung-dung-cua-ios-android-va-windows-phone-467

 

Top 10 Things Every Developer Must Do

Oh wow! I am revisiting this article after six years. Things have changed quite a bit since then.

-------------------------------------------------------------------------------------

Over the 18 years of my software development career, I have seen many mistakes that developers repeat again and again. 

Here is my top 10 list and more.



1. Missing Documentation

I have seen developers who do not like to write documentation. Obviously, there are tight deadlines and deliverables but it does not take too much time to write about the functionality you are implementing. If you spend one hour for every seven hours of code you write, it will go a long way, and eventually it will save you a lot more time.

OK, let's try to understand this with an example.

In the code sample below, you can see a method called MessySample. I created two ArrayList objects and added some integer and string values to it. Once added, the code simply displays the output.

private void MessySample()  

{  

    ArrayList obj = new ArrayList();  

    obj.Add(32);  

    obj.Add(21);  

    obj.Add(45);  

    obj.Add(11);  

    obj.Add(89);  

    ArrayList obj2 = new ArrayList();  

    obj2.Add("Mahesh Chand");  

    obj2.Add("Praveen Kumar");  

    obj2.Add("Raj Kumar");  

    obj2.Add("Dinesh Beniwal");  

    int bs = obj2.BinarySearch("Raj Kumar");  

    Console.WriteLine(bs);  

    foreach (object o in obj2)  

    {  

        Console.WriteLine(o);  

    }  

} 


Technically, there is nothing wrong with this code.

 

The only problem is, there is no proper documentation. Unless I go through the code, I don't know what this method is doing. Also proper naming conventions and readable variables can help. If another programmer writes code and uses the same name variables, obj1 and obj2, and at some point, you try to find all variable references with the same name, you may end up going through some unwanted code. Here is the same code but documented:

/// <summary>  

/// This is a MessySample method that shows how we can write messy code  

/// </summary>  

private void MessySample()  

{  

    // Create an ArrayList object to store integer items  

    ArrayList obj = new ArrayList();  

    obj.Add(32);  

    obj.Add(21);  

    obj.Add(45);  

    obj.Add(11);  

    obj.Add(89);  

    // Create an ArrayList object to store string items  

    ArrayList obj2 = new ArrayList();  

    obj2.Add("Mahesh Chand");  

    obj2.Add("Praveen Kumar");  

    obj2.Add("Raj Kumar");  

    obj2.Add("Dinesh Beniwal");  

    // Apply binary search  

    int bs = obj2.BinarySearch("Raj Kumar");  

    // Display index on the console  

    Console.WriteLine(bs);  

    // Send ArrayList items to the console  

    foreach (object o in obj2)  

    {  

        Console.WriteLine(o);  

    }  

}  



 

2. Messy Code

Keep it clean. Don't be messy. Writing code is an art. Make it cleaner. Make it pretty. Format it. This part is more about focusing on naming conventions and proper representation of your methods, properties, and variables.

Here is my original code sample. As you can see from the code below, I have two ArrayList objects and the code adds some integer and string values to them. 

private void MessySample()  

{  

    ArrayList obj = new ArrayList();  

    obj.Add(32);  

    obj.Add(21);  

    obj.Add(45);  

    obj.Add(11);  

    obj.Add(89);  

    ArrayList obj2 = new ArrayList();  

    obj2.Add("Mahesh Chand");  

    obj2.Add("Praveen Kumar");  

    obj2.Add("Raj Kumar");  

    obj2.Add("Dinesh Beniwal");  

   

    int bs = obj2.BinarySearch("Raj Kumar");  

    Console.WriteLine(bs);  

   

    foreach (object o in obj2)  

    {  

        Console.WriteLine(o);  

    }  

}  

 

The following code is a clean code with proper comments and naming conventions. As one of the comments suggests, if you use the proper method, variable, and other object names, you will need very little or no documentation. From the code below, I can clearly see that numberList is an array of numbers and authorsArray is a an array of author names.

/// <summary>  

/// This method is a clean sample that shows how to write  

/// clean code.  

/// </summary>  

private void CleanSample()  

{  

    // Dynamic ArrayList with no size limit  

    ArrayList numberList = new ArrayList();  

    // Add 5 Integer Items to ArrayList  

    numberList.Add(32);  

    numberList.Add(21);  

    numberList.Add(45);  

    numberList.Add(11);  

    numberList.Add(89);  

   

    // Create Authors Array List to store authors  

    ArrayList authorsArray = new ArrayList();  

    // Add Author names  

    authorsArray.Add("Mahesh Chand");  

    authorsArray.Add("Praveen Kumar");  

    authorsArray.Add("Raj Kumar");  

    authorsArray.Add("Dinesh Beniwal");  

   

    // Display and apply binary search  

    Console.WriteLine("====== Binary Search ArrayList ============");  

    int bs = authorsArray.BinarySearch("Raj Kumar");  

    Console.WriteLine(bs);  

   

    // Display authors to the console  

    foreach (object author in authorsArray)  

    {  

        Console.WriteLine(author);  

    }  

}  



 

  1. Copy, But With Love

    Code sharing, code reusability, and open source are very common practices today. Thank Google, C# Corner, MSDN, CodeProject, StackOverflow and other online websites for providing tons of free code. It would be foolish for us not to use the same code that is already written and available.

 

So copy, but copy with love. The first thing you need to do is understand the code and verify it. There is so much code out there. Some code is written by experts. Some code is written by amateurs. You must test your code. Once tested, you may also want to check with the terms and conditions and licensing of the code. Sometimes, you may not realize it, but a person who has shared code may want you to use his copyright terms. 

  1. Think Outside of the Box

    If you are involved in a project that was already developed by some other developers, do not just follow what other developers have written. Before you follow the same steps, think if the way the prior code was implemented is the right way to do it. I may have shared some code on C# Corner but that does not mean I have written the most efficient code. You may come up with better ideas.

 

For example, on many websites, you may find code that is written using C# 2.0. The same code is applicable today as well, but in C# 5.0, you may write the same code in an optimal way.

5. Testing! Testing! Testing!

This is one of the areas where I find most developers who are rushing to deliver their code are not testing it thoroughly. Not only must you functional test your code, but also stress test it. This I have seen over and over: When a new functionality is added to a project, there may be chances that the code may have affected other areas. You as a developer need to test that all areas are tested well before it is given to your Integration Manager or deployed on the Test Server.   

Read here: Why Every Developer Should be a Good Tester

 

  1. Debug! Don't Guess

    Don't trust yourself unless you're an experienced programmer. Don't guess what your code would do unless you have already used that code before. Always debug the code before even running it. When I write a piece of code for the first time, I go line by line, add my debug variables and use debugger to step through line-by-line and variable-by-variable to see if the values of these variables are passing my tests. You can avoid this if you use #7.

    7. Write Test Cases

    Visual Studio 2010 and later versions come with a very powerful tool to write test cases for your project. Use it. You can also use third-party open source products such as Nunit. 

    8. One Thing at a Time

    I have seen some programmers write code for one week straight and then do the testing. Write code based on a smaller unit of functionality and test it before you move to the next functionality.

    9. Think Modular

    I remember the days when a code file would have thousands of lines and just keep going and going. If possible, try to break down your code into chunks based on the function, and create a method or a class as applicable. Use proper Object Oriented Programming best practices. Use proper design patterns. Make a good use of libraries, classes, functions, and other modern programming language features that are available to you. 
  2. Do Not Trust Your Testing Team

    Do not rely on your testing team and think that they will find all the bugs. You are the one who knows code and functionality more than anybody else. You test it and then hand it over to the testing team.

    11.    Why don't you add one ;).

    What is your list? Please share!


    12. Good Team Player

    Building software is teamwork. One person can build small software, but when you work on large projects, it is a team effort. A developer must be a good team player. It does not matter how smart or expert you are, if you are not helping your team and not sharing with others, the project will suffer.

 

  1. Ask Questions. Ask Again and Again

    Some developers (I was the same in my early career) think asking questions of a client or manager will make them look foolish or stupid. This is not true at all. I would rather explain the same thing four times than get something that is not right. So make sure you get the requirements right before starting to write code.

 

  1. Be Ahead. Give 110 Percent

    This is from my personal experience. I was named the "crack programmer," "coder on crack," and other names for solving problems instantly. Most of the time, I got the requirements and they were done before the deadlines. So when my manager would come ask, "Is that feature done?" My answer would be, "Yes, it is live already."  

    There are three ways to work:

    1. Do what you were told to do.
    2. Do less than what you were told to do and still be working on it.
    3. Do more than what you were told to do.

    Do not assume that your boss knows more than you. He/She may know more than you but it does not mean that you cannot give your ideas or suggestions. You may have better ideas. Even if they are not better, it does no harm to open up and let him/her know.

    15. Got any advice? Share with us here . . . 

 

LINK: http://www.c-sharpcorner.com/blogs/top-10-things-every-developer-must-do

Top 8 Things You Should Not Say To a Developer

8 điều bạn không lên nói với nhà phát triển (Developer)

Last week, I wrote an article, Top 10 Things You Should Never Say To Your Boss. This week, I am writing the other side of the coin and focusing on the team owners and what they should not say to their developers.

I've been working in the software industry for 17 years. Most of the points discussed here are based on my personal experience. The article is written for business owners, project owners, technical managers, team leaders and seniors who manage a team of developers.

One thing worth mentioning is that most bosses have bosses. If an employee is trying to do something that is in the best interests of the boss's employer it is actually the boss that should obey the employee. That is of course an over-simplification; it is a general concept, not a rule.


Here is a list of my things not to say to a developer.

I don't have time for this.

So you're busy and you really don't have time for your developer. I suggest you find some time. By not giving time enough to your developer, you're actually hurting the project and hence yourself.

There are many possible solutions. A really good boss is creative, flexible and open to alternatives. One solution is to get it in writing and when you do, give it the attention it deserves. It could be that a developer has already tried to communicate in writing. If so and you tell them you do not have time then that leaves the employee without a reasonable solution. The problem might be personal or the problem might be a problem for the company, either way ignoring it has consequences. 

Just do it the way I like it

Coding is not food. Your taste does not matter as long as the developer is doing his/her job. These days, the technology and features are being released rapidly. You should encourage your developers to adapt the latest features, trends and technologies that benefit the organization and project. It is your responsibility to know what is best and that is not easy to do. You need to analyze the costs and benefits of the latest features, trends and technologies. It is reasonable to restrain developers from using something just because it is new but it can also be a mistake to avoid converting to something new. The longer you delay implementing something new, the more it could cost to do the conversion.

One of my long time clients asked me to review one of his projects. I met the architect and the tech lead of the project and started the code review. The project was developed using .NET 4.5 and Visual Studio 2013 but what I saw was the developers still using coding that complied with .NET 1.1 and 2.0. I questioned the architect and he replied, this is the way like it. We've been doing this for a long time. It is easy to understand. The problem is that the longer they delay developing code using the latest capabilities, the more it will cost to convert when it becomes necessary. 

Just leave it. I will do it.

In my early days, I made this mistake myself. Sometimes to move things faster, you end up doing it yourself. I suggest you stop that. To scare your development and grow your organization and team, you must know how to train your developers. I know it can be very frustrating from time to time but for the long run, it will actually help you.

One of the key attributes of a good leader is an ability to create his/her own replacement. In software development, as a project owner, you must consider “what if”. What if I am sick tomorrow?

We use computers to do as much of the detailed work as possible. The philosophy is that it frees us to do the things that computers cannot do. You need to delegate to your employees everything they can do so it frees you to do the things that they cannot.

Also avoid keeping the fun stuff for you to do yourself. Employees are likely to resent that.

You're taking too much time

You must determine why a developer is taking more time than your expectations. There must be a valid reason behind it. If the developer is not skilled, it is your job to find a replacement. If a developer is not motivated, it is your job to figure out why. Again, it all falls on you. All of that can of course be difficult to do. It is easy to avoid doing it. A common way to avoid doing it is to blame the developer for not getting the work done on time and when that is done to avoid finding problems, there are consequences.

Your projects will proceed much more smoothly if you are realistic about the time required. Setting unrealistic deadlines might get the work done on time but end up being very costly later. Employers need to attempt to employ developers that are able to make reasonable estimates that can be relied on. If however a deadline is used because the employer thinks the employee is not productive then that is a problem. The ideal is to have a trustworthy employee that is trusted.

One suggestion is to maintain a record of estimates compared to actual times, especially if that is done for many developers and many projects. There are software systems and other methodologies available to help get other opinions of time estimates.

He can do faster than you

Everybody has their own pace. Everybody has their own strengths and weaknesses. Some people are fast and some are perfectionists. Some are slow but workhorses. When you hire a new employee, it is your job to determine their pace and skills and maximize what they are capable of.

Be careful about judging an employee as being faster if they only seem faster because they put in more hours. Longer hours might seem to be an advantage but it is not necessarily an advantage. If for example a developer actually puts in more hours to get something done faster then it might be a symptom of carelessness if they must do a lot of testing. An extended amount of time spent testing could result in costlier maintenance in the future if the testing begins with buggier code. It is your responsibility to determine what applies.

Do it now

Yes it is very difficult not to say this. Trust me, I've been a developer. I have worked under projects. I have managed teams and projects and now I am managing companies. There are many times, I want things now.

But I know, I am wrong. Sometimes things can't be done now.

Think of it in terms of the amount of time spent switching gears from one thing to another. You should assume that asking a developer to do something that takes 10 minutes will take an hour away from something else. That is not a problem if it is done once and/or when it is important enough but the cost could accumulate if done carelessly.

Can you use a template or this is really simple

Oh, this one pisses me off. This does not apply to a technical person. This usually comes from amateur business owners who do not understand software at all. I hear this a lot from non-technical business owners.

Oh yea, if it's that simple, why can't you do it yourself?

A student can do it

You've just not only insultated your developer, but you've also demoralized him/her. Reality is, no a student can't do it. That's why you hired an experienced developer and pay lot more than you would pay a student.

Summary

In this article, I talked about some things you should not say to a developer. I am sure you have your own list. I would like to get your feedback and your items that you don't want your boss or other people to say.

LINK: http://www.c-sharpcorner.com/UploadFile/mahesh/top-8-things-you-should-not-say-to-a-developer/