Good morning

2019

Videos

1 — M96: Freelancers are a pain, but they are your only hope if you want the quality to go up
2 — M97: Let your followers be your best censors helping you think more logical
3 — M103: Large software companies will have to work with freelancers, b/c they will have no choice
4 — M107: Make your GitHub project look attractive and contributors will come
5 — M111: Use open source projects to beat the boresome of the office work
6 — M114: The performance of programmers can be measured, with the right metrics
7 — M116: Which license to use for an open source product?
8 — M121: Don't be frustrated by the enterprise chaos around you, conquer it!
9 — M120: Don't wait for your manager to tell you what to do, do what you think is right (open source)
10 — M124: Put your talent away and learn new skills when working in an enterprise
11 — M129: Niche narrow-skilled developers will earn more than others
12 — M142: Your management is perfect only if you can pay everybody by results, not by time
13 — M148: How do you ask your manager to raise your salary? You don't!
14 — M151: Don't judge your people, let the market do it much better
15 — M160: Traditional top-down planning doesn't work, try better alternative
16 — M155: The best and the only way to reward top talents is recognition through fair competition
17 — M82: Is it possible to open the entire source code base and still make business? Definitely.
18 — M83: Strong opinions loosely held is not a problem, the absence of an architect is
19 — M88: If you are working on a prototype for longer than two weeks, you are doing it wrong
20 — M94: It is impossible to make a full-timer deliver results, unless they want it
21 — M99: Don't punish your team for technical mistakes, use audit results to prevent future troubles
22 — M199: Unit tests are the Safety Net that you can't afford to not use
23 — M198: It's impossible to be a software expert with an empty GitHub account
24 — M197: The worst demotivation for A-players is their equal appreciation with C-players
25 — M196: Maintaining a creative spirit in an enterprise is hard, but possible
26 — M195: Static analyzers find bugs in code, but who finds bugs in programmers?
27 — M190: Make sure the bugs you report explain the simplest possible scenarios
28 — M188: I don't think ML will ever be able to write code
29 — M187: Why did I return a new MacBook Pro 2021 worth $5500 back to Apple?
30 — M194: Keep a balance between work for money and investments into yourself
31 — M185: CTO has to write code and delegate management to PMs
32 — M193: What is fun and joy for you, being a programmer?
33 — M184: Keep your best programmers from maintenance mode
34 — M192: Find a way to structure your opinion after each interview of a new candidate
35 — M186: Make sure your CV has something nobody else has and you'll be fine
36 — M191: When a bug report is not as simple as it can be, don't fix it
37 — M183: Start making a software product from configuring its build pipeline
38 — M189: How would you decide who deserves to be authors of a published paper?
39 — M182: Open source products are made by young and hungry
40 — M181: How do you manage under-performers? You ignore them.
41 — M180: Pre-commit Hook is a wrong idea
42 — M179: Calibrated Achievement Points (CAP) to measure R&D productivity
43 — M178: Try to focus your team on artifacts and their delivery status
44 — M177: Auto-formatters do more harm than good for programmers
45 — M176: Often digital discussions don't work because there is no decision making process defined
46 — M175: When the customer asks you to convince them, just don't
47 — M174: Your personal goals go first, team and project goals next
48 — M173: The inspiration for coding comes from personal projects
49 — M172: When requirements are vague, you don't quit, you make your own product
50 — M171: submit your research to ICCQ Student Research Competition
51 — M169: Before you write a good text make sure you like how it looks
52 — M170: recruiters may do a better job if listen to us programmers
53 — M168: a professional software engineer may also be a scientist/researcher
54 — M167: Sometimes you have to be an imposter, either you like it or not
55 — M166: Challenging tasks and objective appraisal is what keeps top performers in the team
56 — M165: Contribute to the community if you want to do "good"
57 — M164: Fixed-Price contracts are much worse than Time&Material
58 — M163: If you as a manager don't punish wrong-doing, the team will punish you
59 — M87: If you are afraid of being replaced, you are not a good programmer
60 — M92: We in Zerocracy use Boost Factor to help architect motivate programmers
61 — M133: How much do you care about open source nature of your project?
62 — M161: It's not the competition that destroys a team, but unfair rules
63 — M162: When punishment is justified in a software team?
64 — M159: If your objective is to keep the team intact, competition is not for you
65 — M153: How managers in self-managing orgs judge your performance?
66 — M152: There is no management without personal responsibility
67 — M150: Competition is good, while badly chosen tools and rules may be dangerous
68 — M149: Rewards without quality control will only hurt, but so what?
69 — M145: Internal competition is what your team needs to achieve results
70 — M147: The quality of code review(er) can be measured by the frequency of rejections
71 — M146: Collaboration and teamwork are highly overrated in software teams
72 — M143: Daily reports are a perfect guilt-triggering instrument for a lazy team
73 — M141: Lines of Code is a good metric if your management is perfect, otherwise it will hurt
74 — M140: Morning stand-ups are evil, use other management instruments instead
75 — M139: It seems that better programmers write more lines of code
76 — M138: Morning stand-ups are nothing else but guilt-triggers
77 — M135: Don't ask for approval, educate them so that they make the decision themselves
78 — M137: Don't ask your programmers to estimate, tell them how much you have
79 — M134: Don't blame the situation for the mess in the code, it's only your fault
80 — M132: Your pet projects are the best contribution to your resume
81 — M130: The root cause of most software problems is the chaos in the code
82 — M131: Be aware of conflict-of-interest concerns when you open source while being employed
83 — M128: Don't quit failing projects, quit those that fail you
84 — M127: The ability to explain a problem so that it's understood is the most important soft skill
85 — M126: Use open source projects to build yourself a support group
86 — M123: One README should be enough for any open source project
87 — M125: When you contribute to your project altruistically, you are killing it
88 — M122: Don't help them, instead use their free contribution to improve the product
89 — M85: The source code is just a part of a software project, not the biggest one
90 — M86: The README file must be the only provider of product specification
91 — M91: Full-timers want to look smart, freelancers want to deliver results
92 — M118: Deploy your ready-to-use open source artifacts into immutable repositories
93 — M89: Deliver your trust continuously, not discrete
94 — M119: How to be a jack of all trades and not hate it?
95 — M90: RUP is a framework, Agile is a philosophy; just like Zerocracy and XDSD
96 — M93: To become a good programmer you have to find a project that rejects your mistakes
97 — M156: Competition doesn't contradict with collaboration
98 — M115: Going along with large open source projects is a perfect strategy for newbies
99 — M98: If you think that your team is doing fine, you are a bad manager
100 — M117: Breaking responsibility down is the responsibility of a manager/architect
101 — M112: Put as much as possible on GitHub, no matter what it is
102 — M113: Your coding should be a social activity and GitHub is your social network
103 — M157: We must measure productivity, but using the right metrics only
104 — M110: Professional developers enjoy being punished by static analyzers
105 — M109: Open your sources piece by piece, not all at once
106 — M108: Your job is to prepare your open source project for the future community
107 — M104: Refactoring without a ticket means stealing project resources
108 — M106: Very soon all important software projects will open their sources
109 — M105: Open source developers inevitably have better soft and tech skills
110 — M101: Every non-standard design decision you make is a maintainability risk
111 — M154: Proper competition prevents cheating in a software team
112 — M102: Zerocracy may look like utopia for you now, but eventually you will be there
113 — M100: Tech audits help you identify the gaps between your codebase and industry standards
114 — M95: Only lazy and immature programmers are afraid of penalties and punishment
115 — M50: Testing is the process of confirming that the software has defects (JPoint talk rehearsing)
116 — M51: Don't hide error stacktraces, make end-users part of your quality control instead!
117 — M54: Make sure you control your programmers and do it explicitly and openly
118 — M84: Don't chase your team members, make them chase you
119 — M55: The programming language you choose must match your project business objectives
120 — M81: How to make your GitHub repo popular? Eight things to pay attention to.
121 — M64: You want your programmers to be your enemies? Pay them monthly.
122 — M79: Make as many open source libraries as possible, eventually one of them will become a success
123 — M58: Don't expect UI/UX people to work in microtasking mode, they are too creative for that
124 — M57: Tech startups fail mostly because of software development incompetence
125 — M80: Every two weeks you should hire a new auditor to review your software project
126 — M77: Lines-of-Code don't show anything meaningful, but Hits-of-Code are pretty accurate
127 — M76: Learn Rational Unified Process to understand SDLC better
128 — M78: Programmers are not your property, don't invest in them!
129 — M73: It is your job, as an architect, to convert client's requirements into tickets
130 — M72: Zold, like any other young cryptocurrency, needs master nodes to survive
131 — M71: Motivating programmers by equity or profit sharing is a bad idea, it doesn't work
132 — M69: Write tutorials instead of training and teaching
133 — M68: Is it necessary to be a full-timer first, in order to become a freelancer? Yes, why not!
134 — M66: If you will manage programmers the way Google does it, you will lose
135 — M65: If you need to learn the code around your microtask, don't do it! Create a new ticket.
136 — M52: Three-branches release model: Master-Candidate-Live
137 — M41: Six steps to a better speaking English for a software developer
138 — M43: Technical interviews are pointless, pay attention to these five things instead!
139 — M40: To achieve quality you should numberize your Plan-Do-Check-Act cycle and its participants
140 — M38: Request-for-Proposal (RfP) is how the matchmaking process works in Zerocracy
141 — M36: Protect yourself against stupid managers—become their good friend!
142 — M18: Writing unit tests or not is not the decision project makes, it's your professional choice
143 — M13: A message without a context is unprofessional and very annoying for the listener; don't do it!
144 — M10: How do you enforce TDD in a team? Put your gang together first. Then use it as a leverage.
145 — M7: Don't be afraid to ask difficult qstns before you get into a partnership, or get ready to lose
146 — M6: Keeping all source code in a single monolithic repository is a terrible idea!
147 — M4: A full decentralization is a myth, since the source code inevitably is under someone's control
148 — M158: Eliminating team conflicts leads to less collaboration, not more
149 — M136: Any software product has an unlimited number of bugs
150 — M144: Programmers are lazy, either in a good or a bad way, bu they are
151 — M1: Your enthusiasm may only harm the project if you can't deliver it incrementally
152 — M8: Since most tech editors have no idea what they are doing, ignore them
153 — M9: Every time you see an opportunity to open source a piece of code, do it!
154 — M26: Don't be afraid of your programmers, just get ready to fight when they get rich on your idea
155 — M31: What do you do with junior programmers who can't write good code? You train them.
156 — M44: Why do you think you are a senior developer? Who says so? Think again.
157 — M47: What is the difference between Zerocracy and Upwork? We are not competitors!
158 — M67: The future of software development has no offices and no companies, only projects
159 — M70: A software team without conflicts can't produce anything of a good quality
160 — M74: If your project doesn't have a formal Risk List, you are doing management wrong
161 — M75: Your presence in social networks is important for your career as a software architect