SpringOne Tour: The Influential Software Engineer
•
0 gostou•50 visualizações
Date: May 2023 Speaker: Nate Schutta, Software Architect, VMware
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a SpringOne Tour: The Influential Software Engineer
Semelhante a SpringOne Tour: The Influential Software Engineer (20)
Mais de VMware Tanzu
Mais de VMware Tanzu (20)
Último
Último (20)
SpringOne Tour: The Influential Software Engineer
- 2. We tend to view software projects in purely technical terms.
- 3. What language should we use?
- 4. What datastore makes sense?
- 5. What new technology do we all want to put on our resumes?
- 6. Resume driven design is a real thing friends!
- 7. Doesn’t mean it’s a good idea mind you…
- 8. Software practitioners tend to fi xate on technology.
- 9. It’s fun! It’s why many of us get into software in the fi rst place.
- 11. Software education tends to ignore people.
- 12. At our own peril!
- 13. How many of you have skipped a soft skills seminar?
- 14. Most of us learn to navigate those waters via trial and error.
- 15. #ProbablyFine
- 16. This doesn’t come naturally to all of us.
- 17. Technology gave us an escape from messy human interactions!
- 20. It comes with the paycheck.
- 21. Software projects are people projects.
- 22. Full of personalities, emotions and opinions.
- 23. While it is tempting to focus solely on tech, it isn’t enough.
- 24. How do you in fl uence people?
- 25. How do you communicate technical messages to non technical people?
- 26. How do we do all that while still delivering working code?
- 27. Culture.
- 28. Culture? What does that have to do with technology?
- 29. Ignore culture at your own peril.
- 30. Every company has a culture.
- 31. What is yours like?
- 32. “If they don’t change the paint once in a while...”
- 33. Culture gets formed *very* early in a company’s existence.
- 34. Hire, attract, retain based on culture.
- 35. During hiring, often talk about “culture fi t.”
- 36. Culture informs everything we do.
- 37. In both small and large ways!
- 38. The battle over jeans…
- 39. Culture is where good ideas go to die.
- 40. It is *really* hard to change.
- 41. People who have risen to power or excelled in an org…
- 42. Have often gamed that culture.
- 43. Any change to that culture is a potential threat to position.
- 45. Most dangerous six words?
- 46. “That’s how we’ve always done it”.
- 47. –Upton Sinclair “It is dif fi cult to get a man to understand something when his salary depends upon his not understanding it.”
- 48. –Niccolò Machiavelli “[T]he innovator has for enemies all those who have done well under the old conditions, and lukewarm defenders in those who may do well under the new.”
- 49. The Curse of Culture. https://stratechery.com/2016/the-curse-of-culture/
- 50. –Ben Thompson “culture is one of a company’s most powerful assets right until it isn’t…”
- 51. Be aware of your culture.
- 52. How do we change culture?
- 53. “How did you go bankrupt?” Bill asked. The Sun Also Rises by Ernest Hemingway
- 54. “Two ways,” Mike said. “Gradually and then suddenly.” The Sun Also Rises by Ernest Hemingway
- 55. It can be done!
- 56. But it isn’t fast.
- 57. And it isn’t about buying a tool.
- 60. Agile journey…
- 61. We need project rooms.
- 62. What’s a project room?
- 63. We don’t do that, we arrange ef fi ciently placed felt lined boxes.
- 64. Pestered them.
- 65. They relented. We got the worst conference room imaginable.
- 68. But it was as a start.
- 69. Show success, build credibility.
- 70. Serves as a model.
- 71. Here’s what we’d like in the next project room…
- 72. Grew from there.
- 73. Now? IT fl oors are all project rooms.
- 75. Not even a question anymore.
- 76. But it took time. And persistence.
- 77. Simpler if you are a decision maker!
- 79. All data will be exposed through a public service interface.
- 80. Services are *the* communication method between teams.
- 81. No other form of communication is allowed. No direct reads, links etc.
- 82. No back doors.
- 83. All services must be designed to be public. No exceptions.
- 84. Don’t want to do this? You’re fi red.
- 85. Unsurprisingly, things began to change.
- 86. You probably don’t have that kind of clout. Sorry.
- 87. There are other approaches!
- 88. –Adrian Cockcroft “we don’t have these Net fl ix superstar engineers to do the things you’re talking about”, and when I looked around the room at the company names my response was “we hired them from you and got out of their way” https://medium.com/@adrianco/you-dont-add-innovation- to-a-culture-you-get-out-of-it-s-way-2e6148349aae
- 89. – Adrian Cockcroft “You don’t add innovation to a culture, you get out of its way.” https://medium.com/@adrianco/you-dont-add-innovation- to-a-culture-you-get-out-of-it-s-way-2e6148349aae
- 91. Sometimes, it is easier to start a new culture.
- 92. A lab, a special fl oor, a different building.
- 93. Free of typical constraints.
- 94. Allows you to start fresh. With like minded individuals.
- 95. Legacy code.
- 96. We all dream of green fi eld development!
- 97. Free of the shackles of the past.
- 98. This time, we’re going to do it right!
- 99. But we don’t get many of those opportunities. Sorry.
- 100. And, even when we do, things go sideways faster than we’d like.
- 101. You will work with code that needs…changing.
- 102. Sorry. Comes with the paycheck.
- 103. No one get’s it right the fi rst time all the time…
- 104. Iterate!
- 105. Leave the code better than you found it.
- 106. Do what’s right.
- 107. No tests? Write some.
- 108. Smelly code? Clean it up.
- 110. Tend to elevate the developer that “runs into the burning codebase.”
- 111. Without acknowledging they may have actually started the fi re.
- 113. “I try to write tests, refactor the code, improve things…”
- 114. “But my manager wants it done fast…like that person…”
- 115. Who makes things worse…
- 116. Culture kills.
- 117. Praise people for doing things the right way.
- 118. Take the time it takes so it takes less time.
- 119. – Archilochus “We don't rise to the level of our expectations, we fall to the level of our training.”
- 120. Understand total cost of ownership.
- 121. Certain things stand out.
- 123. I know it when I see it.
- 125. Look for levels of indents!
- 126. Odd or old idioms.
- 127. Poorly named variables and methods.
- 128. “Jeff…you named your ship Jeff…”
- 129. Anything that makes you go…
- 130. 🤔
- 131. 🤨
- 132. 🤮
- 133. 🤬
- 134. Are there too many comments?
- 136. “We don’t go there…”
- 137. Low lottery numbers.
- 138. “Only Kathy goes into that part of the codebase…”
- 139. How much of your code is covered by tests?
- 140. There are tests right?
- 141. You can still fail with 100% code coverage!
- 142. Bugs tend to hide where there are few or no tests…
- 143. Want more code coverage? Prominently display coverage stats.
- 144. Be careful with metrics.
- 146. Link metrics to goals.
- 147. Focus on trends.
- 148. Favor short time horizons.
- 149. Adapt and adjust!
- 151. SonarQube, PMD, JDepend, CodeScene, CodeRush, Checkstyle.
- 152. Using a compiled language?
- 153. Don’t just ignore compiler warnings. They’re telling you something!
- 154. IDEs have built in refactoring tools. Leverage them.
- 155. Sometimes you have to… work without a net.
- 156. It is stressful. Write tests.
- 157. Pair with someone!
- 158. Small steps.
- 159. Change a bad variable name.
- 161. Pay down a little technical debt each day/week.
- 162. Don’t neglect the cultural shift.
- 163. Culture is where good ideas go to die.
- 164. All the best practices don’t matter if they are ignored.
- 166. Get buy-in from the team.
- 167. Expect some…discussion. And that is fair.
- 168. Educate. Why are we doing this?
- 170. Be critical of code. Not people.
- 171. Expectations matter.
- 172. We won’t ship bad code.
- 173. All else fails, write with the 3 am rule in mind.
- 174. Avoid complexity.
- 175. – Charles Mingus “Anyone can make the simple complicated. Creativity is making the complicated simple.”
- 176. Software is full of complexity.
- 178. Two fl avors.
- 180. What we do is hard!
- 182. Can’t do anything about it.
- 184. Ways we make things harder.
- 185. Overly complicated tools, noisy technologies.
- 187. All code is legacy code.
- 188. And code inevitably lives longer than we expect it to.
- 190. 😬
- 192. Focus on the human.
- 194. An ounce of prevention…
- 195. Developers come and go. Inevitable.
- 197. Do you have a solid onboarding guide?
- 198. All the one time setup you… forget about. Write it down.
- 199. How do we share knowledge? How do we share values?
- 200. Hard problem!
- 201. Many teams have nothing.
- 202. Or it is really out of date.
- 203. Some systems are too formal requiring tickets and admins.
- 204. 🤮
- 205. 🤬
- 206. People just won’t use them.
- 207. Low ceremony. Wikis. Etc.
- 208. Contact information as well as the on call rotation.
- 209. Links to helpful things like the repo, dashboard link, on call book.
- 210. FAQ.
- 212. Coding standards.
- 214. Glossary.
- 215. Seriously - lots of confusion over terms.
- 216. –Rich Hickey “…most of the big problems we have with software are problems of misconception. We do not have a good idea of what we are doing before we do it. And then, go, go, go, go and we do everything.”
- 218. Projects have ample jargon.
- 219. Many people won’t ask… what does that mean?
- 220. They’ll just live in the dark.
- 221. Whatever helps the team understand.
- 222. Actively share your knowledge.
- 223. Consider a “time capsule”.
- 224. Screen cast or podcast of what you did and why.
- 225. Take advantage of standup, retros, pair up.
- 227. Grab lunch. Even if it is virtual.
- 228. Values matter. “New Rule.”
- 229. If all else fails…
- 230. Golden rule!
- 231. Do it for those that come after you.
- 232. I’d like to tell you it is easy to get everyone to do the right thing.
- 233. It isn’t.
- 234. Time to step out of our technical comfort zone.
- 235. May have to practice some in fl uence skills.
- 236. How do we get the decision makers to buy in?
- 237. What techniques can we use to in fl uence them?
- 239. Find common ground.
- 240. Avoid aggression.
- 241. Listen.
- 242. Have a conversation!
- 243. Can be hard to convince people!
- 244. Two approaches...
- 249. — Ms. Frances Willard “A reform often advances most rapidly by indirection.”
- 250. Approach as equals.
- 251. Rely on the strength of your ideas and your reputation.
- 252. Your reputation speaks for you when you aren’t there.
- 253. Not sure what your rep is?
- 254. Ask.
- 255. May not like the answer…
- 256. But you can work to change it.
- 257. Find common ground.
- 258. Reciprocity rules…
- 259. Be helpful.
- 260. Be respectful.
- 261. Research your ideas.
- 262. Use trusted sources.
- 264. Nothing wrong with bringing help!
- 266. Be prepared.
- 267. Have your story ready.
- 268. Consider things from your manager’s point of view.
- 269. There might be a rational reason for current state.
- 270. Maybe.
- 271. What I told you was true... from a certain point of view
- 272. Over thinking it will drive you nuts.
- 273. Tech is easy.
- 274. Culture is hard.
- 275. Speaking of cultures... what is yours like?
- 276. What does your company value?
- 278. How is technology viewed?
- 279. Strategic asset? Cost center?
- 280. Culture trumps all.
- 281. Be aware of your culture.
- 282. Can you work within those constraints?
- 283. It will inform virtually everything you do.
- 284. We have to sell our decisions.
- 286. What hill do you want to die on?
- 287. Tabs vs. spaces?
- 289. All code is legacy code.
- 290. And code inevitably lives longer than we expect it to.
- 292. 😬
- 294. More or less as soon as it is committed!
- 295. – Ben Solo “Let the past die. Kill it, if you have to.”
- 296. It’s always tempting to nuke and pave.
- 297. Don’t just dismiss existing code.
- 298. Have an app that’s delivered business value for ten years?
- 299. Congratulations!
- 300. Pat yourselves on the back.
- 301. Legacy tends to be derogatory.
- 302. Heritage might be better.
- 303. Can be an amazing learning opportunity!
- 305. Pragmatism.
- 307. Very little room for dogma in software.
- 308. What hill do you want to die on?
- 309. In other words, pick your battles.
- 310. Strong opinions, loosely held?
- 312. Often *very* strong opinions.
- 313. We have to use <name of technology> on this app.
- 314. Why?
- 316. Cool. You know the name. That isn’t a good enough reason.
- 318. Anyone want to argue tabs vs. spaces?
- 319. Pick a format and go.
- 320. Languages are just tools.
- 321. Cloud computing removes the one stack to rule them all constraint.
- 322. We actually can spin up multiple different stacks.
- 323. Polyglot programming isn’t just a pipe dream anymore! http://nealford.com/memeagora/2006/12/05/Polyglot_Programming.html
- 325. Pick the right tool for the job!
- 326. We aren’t forced down the square peg round hole path.
- 327. But.
- 328. There is always a but.
- 329. We have to avoid tech sprawl.
- 330. It’s great right? Each team can use just the right tool for the job!
- 331. Every developer will have their favorite tools, languages, etc.
- 332. Teams will have their pipeline preferences, meaningful metrics…
- 333. Leads to an awful lot of ways to do a given thing.
- 334. How do we staff up? Go, Haskell, Java, .NET, C++, Ruby, Python?
- 335. How many libraries will we need to support all of that?
- 336. Can we stay current?
- 342. It cannot be a free for all.
- 343. You will need some guardrails.
- 344. “Use any language as long as it runs on the JVM.”
- 345. Pick from these 3 fl avors. Won’t work for you? Let’s talk.
- 346. Focus on “paved roads.”
- 348. Here is a well worn path, we know it works, we support it.
- 350. You build it, you own it.
- 351. Sprawl tends to exacerbate our accumulation of technical debt.
- 352. Beware the Galápagos Island project.
- 353. In fl uential developer uses some esoteric language or technology.
- 356. And then in fl uential developer leaves.
- 357. One of these things is not like the others!
- 358. 😡
- 359. (╯°□°)╯︵ ┻━┻
- 360. Who has to maintain it?
- 362. Not it!
- 363. What do you do?
- 364. Suffer with it. Maybe rewrite it eventually.
- 365. Better to avoid that problem in the fi rst place!
- 366. How do I convince my boss that we should use <technology>?
- 368. Pros and Cons.
- 369. Every technical choice involves tradeoffs.
- 370. – Susan J. Fowler Production-Ready Microservices “When we fi nd ourselves presented with technology that promises to offer us drastic improvements, we need to look for the trade-offs.”
- 371. Essence of design.
- 372. To paraphrase Harry Truman…
- 373. Give me a one handed technologist.
- 374. Should we use React or Angular?
- 375. Should we refactor to microservices?
- 376. Should we be on prem or public cloud?
- 378. In many cases?
- 379. && ! ||
- 380. Balancing those opposing forces is the art of architecture.
- 381. No tech is perfect, don’t pretend it is.
- 383. What do you like about it?
- 384. What don’t you like about it?
- 385. What would you add?
- 386. What would you remove?
- 387. Head of Java for a day...
- 389. How does it stack up to alternatives?
- 391. Options across the top.
- 392. Criteria down the left.
- 393. Criteria can be weighted.
- 395. 01234
- 396. How closely does does it map to the criteria?
- 397. Very effective...
- 398. Angular React Documentation 4 3 Community 4 3 Committer diversity 4 4 Codebase 4 4 Testability 4 4 Update history 3 3 Maturity 4 3
- 399. Angular React Stability 4 3 Extensibility 4 4 Support 4 4 Training 4 4 Hiring 4 3 Corporate fi t ? ? Usage 4 4
- 400. What criteria should you use?
- 401. How should they be weighted?
- 402. Up to you.
- 403. You can tip the scales…
- 404. Usually back fi res.
- 405. Sometimes, the strength of your argument is irrelevant.
- 406. Decision may have been made above your pay grade.
- 407. Or there’s just no appetite for what you’re selling.
- 408. “How do I convince my boss we should use X?”
- 409. They might say no. Heck, they will probably say no.
- 410. And there may even be a good reason!
- 411. There is no *one* right way to do something.
- 412. And we are often faced with “least worst” as our best case.
- 413. Be pragmatic, avoid dogma.
- 414. Tools aren’t an identity.
- 415. And sometimes we have to make do with what we have.
- 416. Even if it isn’t ideal.
- 417. Can you live with that?
- 418. Stakeholders.
- 419. Do you know what’s important to your customer?
- 420. Do you know all the stakeholders?
- 421. You may have heard X but what does the stakeholder say?
- 422. Who are the stakeholders?
- 423. Some are pretty obvious!
- 424. Some…not so much.
- 425. Some might not be visible.
- 426. “Level II Players.”
- 427. Not directly involved…but they can help or hurt the project.
- 428. Their presence is felt.
- 429. “The VP won’t got for that…”
- 430. Maybe we need her in the room then?
- 431. Does the mere idea of that person get in the way?
- 432. You can’t negotiate with someone that isn’t there.
- 433. We have to manage our stakeholders.
- 434. Not all stakeholders are created equally...
- 436. Low interest? Probably not a focus area for you.
- 437. High power? High interest? Key people.
- 438. Make sure they get what they need.
- 439. Interest Power High Low Low High Are they happy? Minimal effort.
- 440. High Power Low Interest.
- 441. Keep them informed.
- 442. Be transparent.
- 443. Provide peace of mind.
- 444. Respect their time.
- 445. Let them come to the information.
- 446. Again, don’t waste their time.
- 447. Sometimes they only seem low interest…
- 448. Then something triggers them, and they’re high interest!
- 449. Ask: is there anything to know that isn’t obvious?
- 450. Is there anything special you need to know about?
- 451. Transparency is the key.
- 452. Interest Power High Low Low High Are they happy? Minimal effort. Make or break...
- 453. High Power High Interest.
- 454. Key to success.
- 455. Some are obvious, others not so much.
- 456. Some are so busy they can’t be there.
- 458. They can’t be ignored.
- 459. They can show up at the last minute and unwind everything.
- 460. Engage with them.
- 461. What is the best way for us to get their input?
- 462. Have a straightforward conversation.
- 463. Be proactive.
- 464. Silence is not always golden.
- 465. They might not check up on a regular basis.
- 466. How do we keep them informed?
- 467. High level summaries? Digest format?
- 468. What works for them?
- 469. Again, respect their time.
- 470. Interest Power High Low Low High Are they happy? Minimal effort. Make or break... Are they in the loop?
- 471. Low Power High Interest.
- 472. Sense of importance.
- 473. Get them involved!
- 474. Help them feel seen and heard.
- 475. Extremely useful!
- 476. Take advantage of their passion!
- 477. Their enthusiasm can be contagious.
- 478. They can advocate for you.
- 479. They will often volunteer to help!
- 480. Can I sit with you for a couple of hours while you work?
- 481. Can I interview you about…?
- 482. Could you test this feature for us?
- 483. Can I get your input on this feature?
- 484. Don’t turn away someone that wants to help!
- 485. Disregard high interest people at your own peril.
- 486. If you ignore them, they can sabotage the project.
- 487. Or work against your interests.
- 488. Must understand your stakeholders.
- 489. What’s important to them?
- 491. What are their concerns?
- 492. What is the decision maker in fl uenced by?
- 493. Who has her ear?
- 495. Moving Forward
- 496. New technologies and approaches can be a bit…overwhelming.
- 498. CHANGE BAD!
- 499. Empathy. Compassion.
- 500. How do we approach someone new to the idea?
- 501. “I’m on one of those agile projects…”
- 502. 🙄
- 503. “OK Waterfaller…”
- 504. Technology adoption is a journey.
- 505. They are where you used to be.
- 506. You can help them, you know where the potholes are.
- 507. But they have to walk the path.
- 508. A day in the life…
- 509. Tools will change.
- 510. Culture will change.
- 511. Be patient.
- 514. Don’t be too quick to judge.
- 516. Most people are trying to do their best work.
- 517. And we may not have all the context!
- 519. Be empathetic.
- 520. “Every single one of us is doing the absolute best we can given our state of consciousness.” – Deepak Chopra
- 521. – Martin Fowler “Change your organization or change your organization.”
- 522. Software isn’t just about technology.
- 523. It would be *so* much simpler if it was!
- 524. You don’t have to settle for being just an engineer.
- 525. You can be in fl uential!
- 526. Good luck!
- 527. Nathaniel T. Schutta @ntschutta ntschutta.io Thanks! I’m a Software Architect, Now What? with Nate Shutta Modeling for Software Architects with Nate Shutta Presentation Patterns with Neal Ford & Nate Schutta
- 528. Between Chair and Keyboard Nate Schutta Software Architect VMware @ntschutta Most Mondays, around noon Central https://www.twitch.tv/vmwaretanzu