Good morning

2019

Videos

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