Forem: Tim Bourguignon 🇪🇺🇫🇷🇩🇪

Ryan Hamblin is an experiential learner and other things I learned recording his DevJourney (#159)

Tim Bourguignon 🇪🇺🇫🇷🇩🇪 — Tue, 13 Jul 2021 06:11:45 +0000

This week, I published Ryan Hamblin's #DevJourney story on my eponym Podcast: Software developer's Journey. Among many other things, here are my main personal takeaways:

Ryan's first career took him toward sports, the outdoors, the medical field, and physical disabilities. He loved his job and the field, but he couldn't project himself in a future where he would be earning minimum wage for a long time. So he decided to embrace a 12 weeks program and become a developer.
Before beginning his Bootcamp, Ryan connected with a dozen developers and CTOs, touring their offices and discovering their job.
Starting in a completely new industry was very bizarre for Ryan. Everything was new. He didn't know what product, QA, agile, standup were supposed to be. He told us the tale of how he accidentally committed a whole pet project into the main codebase after doing a "git add ." instead of adding files one by one.
His first job as a developer didn't work out, but he realized that making money and being employed were two different things. This gave him the confidence he needed to rebound and find a new job.
In this new job, Ryan experienced effective mentorship firsthand. For instance, his mentor fed him articles and asked him to analyze what they were doing together in light of those articles. But working with WordPress wasn't his passion. So he went back to school for another Bootcamp. This time focused on Javascript and algorithmic. This was very stressful but also a phase Ryan enjoyed very much.
While his first Bootcamp was very traditional, lecture-style teaching, the second one was overly heavy on pair-programming. The second Bootcamp also made him create a small project and then swap code with another group and add further features. I love this idea. This sounds like the closest you can come to what we do every day.
Ryan said: "to break into a new industry; you have to foster the mindset of being a learner forever", and to learn, "choose the right things to fail at and fail at it enough to start to understand it."
When I asked Ryan how he finds what to learn, he differentiated between what he needs to learn and what he wants to learn. When he is not forced to learn something by his day job, he encourages us to try and understand the big picture. Also, try to recreate the things we learned along the way in another language/technology. I confronted Ryan with Shawn Wang's comment of going deep whenever you have a chance. His answer was along the lines of "in depths, but on the right things. But beware of rabbit holes. Evaluate the value of what you are putting your time into."
On the subject of passion, Ryan said, "coding is awesome, but you don't have to love to code to be a functioning member of our industry." But he also revised his thoughts a little bit, saying that you then shouldn't compare yourself to . They are driven by passion. If you were to compare yourself to them, you would be setting yourself up for disappointment or, even worse: failure.
I asked Ryan what he took from his first experience as a developer (after his first Bootcamp) into his second (after his second Bootcamp), and his answer was "the culture of why." His first manager had the habit of asking "why" all the time. This pushed Ryan to speak confidently about his work and make sure he understood what he was doing thoroughly.
In his first job as an exercise science specialist, Ryan learned experiential learning. The idea is that experiencing something helps you learn it "learning by doing." But the key concept, which is often skipped, is the retrospective.

Advice:

"Learn something by doing it (experientially), and then teach it to someone else, and then give back to your local community."

Quotes:

"I wanted to find something that I enjoyed, maybe not my first passion, but something that pays well enough that I can afford to do the things I am truly passionate about."
"I knew that learning by doing was the best way for me."
"Chose the right things to fail at and fail at it enough to start to understand it."
"You signed up to be a life learner."
"Coding is awesome, but you don't have to love to code to be a functioning member of our industry."
"Do what you love, and you will find a crossover."
"Tying our self-worth with our work is a very dangerous trap to get into."

Thanks, Ryan, for sharing your story with us!

You can find the entire episode and the show notes on devjourney.info or directly here on DEV.

Did you listen to his story?

What did you learn?
What are your takeaways?
What did you find particularly interesting?

Kara Luton went from ballet and public relations to developer and other things I learned recording her DevJourney (#158)

Tim Bourguignon 🇪🇺🇫🇷🇩🇪 — Thu, 08 Jul 2021 20:52:08 +0000

This week, I published Kara Luton's #DevJourney story on my eponym Podcast: Software developer's Journey. Among many other things, here are my main personal takeaways:

Kara's first passion was ballet. After high school, she moved to New York to train as a professional dancer. But after a while juggling her trainee program and school, she realized that she wasn't as much into dancing anymore. So she moved back home, passed a degree in public relations, and worked as a music publicist for a few years. The work was fantastic and glamorous, but she had no work-life balance, and the tasks were very repetitive. She didn't feel mentally challenged. And that's when she discovered CodeHackademy. At first, coding was "like a game she could do for hours." Kara quit almost on the spot and enrolled in a Bootcamp.
Because of her past in PR, Kara is an excellent networker. When she applied for her first job, she crafted emails that helped her stand out. She got quite a bit of pushback because of her Bootcamp education.
When you are interviewing for a company, you are as much interviewing "them" as they are interviewing you. Kara asked them, for instance, "how do you take time for your junior developers to keep growing in their careers?"
During her first job, Kara played catch-up, trying "to be on par with other developers, to level up her Javascript skills" for instance.
Kara tried many different learning mediums: books, text tutorials, but she discovered that she is a visual learner. Thus, she maximized the video and in-person learning experience. That's also why Kara is heavily involved in communities. Kara co-created the Nashville chapter of TechLadies and took over the leading of the Nashville Women Programmers group.
Working remotely as a junior programmer, Kara felt isolated, but her current employer encouraged her to pair-program a lot. And just before COVID hit, she was about to join a Women-Only-Coworking space.
Kara wants to help others grow; that's why she is pursuing an engineering management career in the long run. The company she currently works for, CrowdStrike, has a clear engineering ladder, with a path split at the senior engineer level. That's where Kara sees herself in the future. She has made this clear with her manager, who has been helping her get ready for this, for instance, helping with onboarding and guiding interns.
Kara reaffirmed the importance of feedback. When she was dancing, she was getting feedback constantly. In her first job, Kara was not getting enough of it. Now she found a way to work with her manager to get feedback every week.
"More diversity doesn't mean just having more women on your team."

Advice:

Be patient; you are not going to be the best developer out there out of your Bootcamp.
"It's going to be hard, but you can do it, it's going to take a while, keep practicing and keep going at it, and it will get better"

Quotes:

"I just quit and started coding; for some reason, I dove right in and had no fear"
"You're from a boot camp, you're too green - hey, I learned all this in 3 months, imagine what I can learn in the next three months at your company!"

Thanks, Kara, for sharing your story with us!

You can find the entire episode and the show notes on devjourney.info or directly here on DEV

Did you listen to her story?

What did you learn?
What are your takeaways?
What did you find particularly interesting?

Shahid Iqbal from drug design to software development and other things I learned recording his DevJourney (#157)

Tim Bourguignon 🇪🇺🇫🇷🇩🇪 — Tue, 29 Jun 2021 07:12:25 +0000

This week, I published Shahid Iqbal's #DevJourney story on my eponym Podcast: Software developer's Journey. Among many other things, here are my main personal takeaways:

The beginning of Shahid's technical story goes back to his childhood when he kept on taking things apart and didn't always manage to put them back together.
But all the while, he pursued programming and Computer Science on the side as a hobby. Shahiq was very interested in human bodywork, but instead of going into medicine, he decided to pursue drug design up to a Ph.D., working long hours in a laboratory until he sat down to write his thesis. That's when he realized he felt miserable as if he had flipped a switch, almost overnight. Shahid dropped out of the Ph.D. program and navigated from job to job to pay the bills. That's when he finally landed an IT Administrator job for the NHS (British Social Security).
The first stumbling block in IT is meeting the requirement specs of a job profile: " they are looking for six months experience in X, I have only five months and three weeks, so I won't apply." To put his foot in the door and boost his confidence, Shahid decided to pass Microsoft Certifications. It worked, and he got his first job as a developer.
A contractor he worked with introduced him to a few advanced concepts like DependencyInjection, CastleWindsor, and NHibernate. Even more importantly, he opened his eyes to the world of Meetups and user groups.
One of the critical skills Shahid learned as a Ph.D. student is to hunt for information. This skill proved itself very useful in the future as a software developer.
Shahid is accommodating by nature, and he struggled for a long time until he realized that enabling others to work is a big part of the senior developer role. You shouldn't feel bad you didn't achieve much today if you spent your time enabling others: "if you've helped three people, that's three times more productive than what you could have done yourself."
During his career, Shahid had the opportunity to interview quite a lot of candidates. He explained in length what was essential to him in terms of values, code quality, and so on. Only once did a developer ask to see the codebase. Ensued a formidable discussion about code ownership, tradeoffs, the things we are proud of, and the things we know we screwed up but have to leave in nonetheless. He encourages us to ask!
Shahid took the job-change challenge to a whole new level. He decided to change job and move to another continent during the COVID pandemic. After a Visa-Nightmare, he finally was able to join his company three months ago.

Advice:

"Yes, your first talk is going to be terrible, but don't worry about it"

Quotes:

"I don't remember debugging the turtle"
"In small companies, the roles are very fluid"
"It's not just what you do, it's how you allow others to work"
"Celebrate the successes that others have made, that you might have helped with"
"That was the first time I realized that the interview process mainly was me interviewing them, then the other way around"
"There are a lot of decisions in our codebases that we made a few years prior, with the information we had at the time, and we have never revisited since"
"If I sum up my career, it's a succession of 'Screw it, let's just do it, what's the worst that can happen?'"

Thanks, Shahid, for sharing your story with us!

You can find the entire episode and the show notes on devjourney.info or directly here on DEV

Did you listen to his story?

What did you learn?
What are your takeaways?
What did you find particularly interesting?

Clare Sudbery surfing on her imposter syndrome and other things I learned recording her DevJourney (#156)

Tim Bourguignon 🇪🇺🇫🇷🇩🇪 — Fri, 25 Jun 2021 12:28:38 +0000

This week, I published Clare Sudbery's #DevJourney story on my eponym Podcast: Software developer's Journey. Among many other things, here are my main personal takeaways:

Clare started her coding journey playing sounds on a ZX-Spectrum at a very young age. But then, computers exited her life for a while.
She got a maths and philosophy degree through which she did a lot of logical thinking, but coming from a family of teachers, she was aiming at becoming a math teacher herself. But, before becoming one, she got convinced by other teachers that teaching was not what she had envisioned: "lots of bureaucracy, a little teaching", so she steered away. Then, thanks to a friend, computers came back on her radar.
She then did a "conversion master" to convert her degree into a computation degree and ended up finding a job coding in C++.
During this master's degree, and long after, Clare found herself being the only woman in the room, and the only person in the room who hadn't been coding since their teenage. This made her feel that "she didn't belong here". 4 years into her career, Clare had been promoted to Senior Software Engineer and still was sure of being a fraud.
Clare always wanted to write a novel. So she decided to reduce her work time to 4 days a week, announce that she was writing a book to increase the peer pressure, and started writing.
Clare has a crucial skill; she is very good at persuading people to give her a job. Her first tip in this regard is: "be yourself!"
Clare experienced the "waterfall" nightmare of being stuck, not raising your voice, becoming even more stuck, feeling that you can raise your voice even less, and so on, and feeling guilty throughout the whole process.
After 12 years as an engineer, and after having been unfairly treated and fired, she decided to embrace the career she wanted all along: being a freelance writer and a math teacher. And the warning she had received a few years before was spot on. Teaching was nothing like what she envisioned; she attempted to hold against the pressure, the bullying, and the bureaucracy but finally resigned and went back to software development, this time web development. That place was a learning-heaven, where asking questions was mandatory. Clare entered as an "empty vessel" and took in as much as she could get.
She was promoted as a middle manager on the assumption that women are stronger on the people's side, even though she didn't want to do it.
After moving toward management and seeing a contractor doing the same job as she did and earning twice the money, Clare decided to become a freelance contractor. Her idea was to alternate contracting and writing. After a few gigs, she rented a remote cottage in Scottland to write her new novel. All she ended up doing was fight her writer's block, and realize how miserable she was, being away from code. She finally realized she was a software engineer after all.
Clare had never applied with ThoughtWorks, a renowned company, for fear of the travel obligations. But after a few more companies, Clare was head-hunted by ThoughtWorks and started there as a consultant.
As Clares puts it, in consultancy, you have to be able to land in any company, any team, and any domain and be proficient. Thus the job-title scale is often skewed. For example, a lead engineer in a product company would be a senior engineer in a consultancy. And consultancies often sell their people a level higher than where they are, e.g., selling seniors as leads, following this pattern. That was terrifying. Clare faced a real case of Imposter-Syndrom and making herself sick over it. And the only person giving her bad feedback was herself.
Since then, Clare has followed the habit of writing down at the end of every week all the things she did well that week.

Advice:

"Make a note of every tiny little success"
"Ask for feedback and write it down to read on the bad days"
"Use your skills to build things and make a note that you did it"
"It is allowed to be self-indulgent, but it's OK. If other people deserve kindness, so do you"

Quotes:

"I'm very good at persuading people to give me a job"
"I had a failed career as a writer and a math teacher, a miscarriage, I had been made redundant in my IT job; it felt like my life had been a series of failures and disappointments, I was determined to prove there was something I could do"
"I had been sniffy about people doing computing in their spare time. But then I chose to put it on its head and see my job as a treat, being paid to do my hobby."
"I do tend to get bored and fidgety, I must confess"
"What I enjoy is being part of a team and building relationships with my coworkers that I missed as a contractor"

Thanks, Clare, for sharing your story with us!

You can find the full episode and the show notes on devjourney.info or directly here on DEV

Did you listen to her story?

What did you learn?
What are your takeaways?
What did you find particularly interesting?

Sandra Parsick from QA-Engineer to Java-Champion and other things I learned recording her DevJourney (#155)

Tim Bourguignon 🇪🇺🇫🇷🇩🇪 — Wed, 16 Jun 2021 10:06:28 +0000

This week, I published Sandra Parsick's #DevJourney story on my eponym Podcast: Software developer's Journey. Among many other things, here are my main personal takeaways:

Hooked on video games by her cousin, at the age of 12, Sandra found herself selling newspapers to pay for her first computer. And that is when her "family computer support career" started. In high school, Sandra took Java programming classes, which set her up on the path she has been on since.
Sandra went through a computer science degree and started working as a QA-Engineer. After one year, she strong-armed herself into a software engineer position and never left it since. But this year has been incredibly valuable. She kept this testing mindset, and it has served her well in creating robust software that other QA-Engineers cannot break easily.
When you repeatedly start your application to test it manually, you would be better off having automated it. This is one of the good things Test Driven Development is bringing us. And don't forget that you can refactor those tests as well 😉
Early in her career, Sandra was mentored by Jürgen, a colleague who took a keen interest in seeing her grow.
When Sandra left the startup she worked for and joined a bigger corporation, she missed the heavy exchange about tech. That's when communities entered her life, first via the Softwerkskammer. It was her way to find "other Jürgens."
Sandra then started sharing her knowledge amongst those communities: "Sharing my knowledge was like a test, to know if I understood it."
Her first conference talk involved a lot of live coding. After a failed experience with no internet connectivity, she moved toward video recordings for those live codings. Then she can also describe what is happening instead of concentrating on writing the right code.
Since then, Sandra has held many talks, co-organized conferences, and been on conference committees. But she also started writing articles. This process helps her "structure her thoughts." I agree with this. I usually start with a few tweets, write about a topic on my blog, craft a short talk, then an article, and finally an extended presentation. Each step is valuable in itself!
"Say yes to everything, be open-minded to try out as much as you can, make your own opinion and decide if you want to repeat the experience."
When I asked Sandra if she has a roadmap for herself, she answered that she knows what she doesn't want to do. But for the rest...

Advice:

"Whatever you do, it is rarely a one-way street"

Quotes:

"Listen to your seniors and ask why"
"When I sail, my laptop stays at home, and my phone is off, and it is awesome"
"When I come back from a sailing trip, I have so many ideas for talks and articles"

Thanks, Sandra, for sharing your story with us!

You can find the entire episode and the show notes on devjourney.info or directly here on DEV

Did you listen to her story?

What did you learn?
What are your takeaways?
What did you find particularly interesting?

Anand Safi is setting people up for success... and other things I learned recording his DevJourney (#154)

Tim Bourguignon 🇪🇺🇫🇷🇩🇪 — Tue, 08 Jun 2021 08:55:58 +0000

This week, I published Anand Safi's #DevJourney story on my eponym Podcast: Software developer's Journey. Among many other things, here are my main personal takeaways:

Anand decided early in his life that he wanted to go toward Maths and logic, so he chose an engineering curriculum. During his first year, he found that "information technology" (instead of computer science) was the best match for his interests. When he made that choice, he had a very narrow view of the whole industry; he didn't realize how many career paths there were. One can, after all, become something else than "just a developer." But the curriculum he followed didn't teach much of the "other" skills one needs to become a well-rounded software engineer.
At the end of his studies, Anand felt he wanted to see the bigger picture. That's why he decided to enroll in a Masters's degree in the USA. He got more pieces of the puzzle but looked for more. So following his master's degree, Anand started working for eBay as a QA Engineer and got to observe the software engineering world from the "poking holes at it perspective."
When Anand became a software engineer, he kept this analytical mindset of breaking things first. Always trying to find the flow, break down tests, find the happy path and the things that can trip the users, the edge cases, etc.
Anand described the purpose of an internship as getting someone a taste of what our industry has to offer. I like to see it framed this way. Way too often, interns are seen as cheap labor to feed the mechanical Turk. Anand's first internship was precisely like that. There was a lot of shadowing other employees and presentations from him to explain his learnings. When Anand onboards people nowadays, the first question he asks himself is: "did I set up this person for success? did I have the meaningful conversations to put them on the best track in their new role?"
The first step toward engineering management is to show some leadership. Everyone can do that. Anand started owning the whole development process, making it easy for his managers to lead him. But Anand reminds us that engineering management is not a promotion; it is a different career path, a new role, and a bag of responsibilities. With it came a whole new definition of "success," which has to do with making others rock!
There are a few topics that Anand tries to bring across in his mentorship, among which: "Listening and asking the right questions" or "Not spreading yourself too thin."

Advice:

"To find a mentor, leverage your networks and find someone who is in the role you want to have in a few years"

Quotes:

"The way teams work is by using the collective strengths"
"Management and leadership start at any level of your journey"
"There is more than coding to software engineering"
"Mentoring is about developing the mindset and how to approach any given situation"

Thanks, Anand, for sharing your story with us!

.ltag__user__id__47770 .follow-action-button { background-color: #0030b3 !important; color: #ffffff !important; border-color: #0030b3 !important; }

Anand Safi

Engineering Manager | Technical Leader | Advisor | Board Member | Tech Mentor

You can find the whole episode and the show notes on devjourney.info or directly here on DEV

Did you listen to his story?

What did you learn?
What are your takeaways?
What did you find particularly interesting?

Clifford Agius is a developer flying a Boeing 787 for fun, and other things I learned recording his DevJourney (#153)

Tim Bourguignon 🇪🇺🇫🇷🇩🇪 — Tue, 01 Jun 2021 06:20:29 +0000

This week, I published Clifford Agius's #DevJourney story on my eponym Podcast: Software developer's Journey. Among many other things, here are my main personal takeaways:

Cliff grew up in east London, nose up, looking at planes taking off. Even though he aced Maths and Science, he had trouble getting through school and ended up joining a new electro-mechanical engineering apprenticeship with Ford Motor Company. Looking back, Cliff regards his apprenticeship at Ford very highly. He thinks it was the best for him, and he would encourage anyone on this path. There, he discovered PLCs (Programmable Logic Components) programming. But during all this time, he was looking up.
He then got his private pilot license and learned what he needed to do to become a professional pilot. 2 years and ~90K£ later, he got his "wings"... right after September 11. It was hard to find a job. He continued contracting for his former company during this time, which is an excellent example of why you should NEVER burn bridges! Later on, he finally got a job as a pilot, worked his way up, and joined British Airways to fly a Boeing 787 Dreamliner.
I asked Cliff why he wanted to become a developer while he was living his dream? His answer was clear. Due to JetLag, he was often awake when everyone was at work. So he started doing websites for friends, and one thing leading to the next, he woke up having a side business he loved as well!
Doing client projects, he stumbled upon ASP, .NET, C#, and finally Xamarin. Being an electrical engineer, IoT also became an ideal subject. He found his sweet spot at the junction of those two and even contributed to the Xamarin codebase.
One of Cliff's main side projects is building on the Open-Bionics source code to 3D-print prosthetics. He now managed to bring down the price of such prosthetics to less than 500£. His goal (before COVID) was to pack a few 3D printers, filaments, and gear and fly them to hospitals in India and Pakistan, where Cliff has contacts. Hopefully, this will restart as soon as COVID cools off. Follow his account on Twitter for more information about this.
Many skills cross over from one domain to the other. One example Cliff gave is decision making: "in aviation, we make decisions very early, and review it regularly, and revise if needed."

Advice:

"Always be learning"

Quotes:

Me: "Do you sleep?" Cliff: "yes, I sleep on the plane!" 😁
"When you remove yourself from an office, and stick yourself in a hotel room in Seattle at 4:00 and turn off your phone, there is no distraction, so you can crush out so much work"
"I love flying, this is my passion, I get paid to do my hobby"

Thanks, Clifford, for sharing your story with us!

You can find the entire episode and the show notes on devjourney.info or directly here on DEV

Did you listen to his story?

What did you learn?
What are your takeaways?
What did you find particularly interesting?

Shawn Wang joined the "fine I'll do it myself" team... and other things I learned recording his DevJourney (#152)

Tim Bourguignon 🇪🇺🇫🇷🇩🇪 — Tue, 25 May 2021 08:43:26 +0000

This week, I published Shawn Wang's #DevJourney story on my eponym Podcast: Software developer's Journey. Among many other things, here are my main personal takeaways:

Shawn first learned QBasic in primary school, but without any role models to show him that it was a valid career choice, he didn't pursue it before his 30s.
While pursuing his finance trading career, Shawn created his own tools. At some point, he realized that he was having more fun creating the tools, so he ditched the finance part. Leaving such a high-paying and rewarding job was a "challenging ego draining endeavor" (sic). He didn't quit cold turkey but instead took over a non-technical product management role on a software product for the trading industry. Doing so, he drifted closer to the developers and learned the field while using his valuable skills. During his time as a product manager, Shawn discovered that he was limited by his inability to prototype. So he joined the "fine I'll do it myself camp" and started learning how to code.
In his finance career, Shawn felt constrained by the idea that you need to be part of a group (which has money) to be in business. SO when he started coding, he joined the indie-hacker movement and started creating out of nothing. This was his liberation.
Is it worth it to invest 17K$ for a Bootcamp? Shawn said yes. 1) Time is money. Paying someone to guide you through a curriculum and answer your questions is worth something. 2) Bootcamps have a hiring-partner network in which companies know the value of your education. This is worth a lot as well.
Companies still see apprenticeship programs more as a service to the community than a funnel to create new hires.
During his first coding job, Shawn realized he was bored at work. So he started learning on the side, visiting Meetups, and learning in public. Everything he did in public tended to work great, whereas what he did in private didn't quite work as well. So he doubled down on the #LearnInPublic and realized he was building a network that would outlive any other job.
Shawn spoke about the 4 tendencies of motivation by Gretchen Ruben: "Obliger," "Questioner," "Rebel," and "Upholder." Obligers are very keen on not disappointing others. In #LearningInPublic, accountability is a great motivator.
Another great aspect of #LearningInPublic is the feedback. "Once you have been publicly wrong about something, you will never forget it" the public becomes your second brain.
Shawn summarized this learning about #LearningInPublic in an essay, and later in a book "The Coding Career Handbook" - 30% discount link. And of course, he wrote the book... in public. He sold an empty PDF for $4000 and started writing, live streaming on Twitch, and filling the document. That's the power of his network.
Shawn later joined Netlify as a developer-experience engineer, which is a rebranding of developer-relations. Since then, he has remained in this field.
Shawn gave us a piece of fascinating advice on how much should you specialize vs. generalize? His advice is "when in doubt, you should specialize, and generalize only when it is necessary." You are always going to be pushed toward more generalization on company time. So it would be best if you specialized on your own terms. There's a lot of common advice on how to learn 101s. But it takes a lot of commitment and effort to become an effort, break over the hump and become an expert. And once you specialized, you can trade this valuable skill.
You should never end the week without having done at least one thing for yourself. If you need a kickstart, read "Pickup what they put down.". The idea is to give feedback, build upon what somebody else is doing. It is the "yes and" of improvisation theater. Not only will you build things, but you will also come in contact with makers. And they crave feedback like anyone! It is a good way to bootstrap your network.

Advice:

Pickup what they put down!

Quotes:

"Programming is one of the few high paying jobs where a formal training is not required"
"I went from VBA to Python to Haskell, while not calling myself a programmer"
"Once you have been publicly wrong about something, you will never forget it"
"When in doubt you should specialize, and generalize only when it is necessary"

Thanks, Shawn, for sharing your story with us!

.ltag__user__id__47766 .follow-action-button { background-color: #6e33a3 !important; color: #bada55 !important; border-color: #6e33a3 !important; }

swyx

Infinite Builder 👷🏽‍♂️ I help people Learn in Public • Author, the Coding Career Handbook (https://learninpublic.org)

You can find the full episode and the show notes on devjourney.info or directly here on DEV

Did you listen to his story?

What did you learn?
What are your personal takeaways?
What did you find particularly interesting?

Chris Coyier, from ceramics to CSS-Tricks and CodePen. Here's what I learned recording his DevJourney (#151)

Tim Bourguignon 🇪🇺🇫🇷🇩🇪 — Tue, 18 May 2021 11:45:12 +0000

This week, I published Chris Coyier's #DevJourney story on my eponym Podcast: Software developer's Journey. Among many other things, here are my main personal takeaways:

Chris's story started with a C64 and games. He didn't do anything else than play on it, but his non-tech-savvy-family, he was the computer kid. And his parents encouraged him in this course. In high school, Chris drifted toward ceramics. A friend of his "was so passionate about it that it made Chris want to be passionate about it too." At the end of high school, he felt there was no future for him in ceramics, so he went to a community college to study computer sciences... and hated every minute of it. He was miserable, so right before graduation, he dropped his major, went back to ceramics, and graduated with a Bachelor of Arts in ceramics... but still being a computer nerd on the side.
As an art graduate, his first job was... doing computer stuff for the printing industry, in short, making the magic happen between "bad design document" and "metal printing plates." But there was no future in there. So that's where Chris's entrepreneurship mindset emerged.
Chris started a side business creating blogs with ads. So he started building websites. Chris dipped his toes into freelancing, but that's not for him. Handling clients is not part of his skillset. He learned that early on and focused on building websites for himself. Even CSS-Tricks was created as a hobby project.
But before his side projects became his full-time job, Chris took a job in an agency making catalogs. He was basically their online person. If nothing else, it gave him the confidence to call himself a web developer and fully embrace this career.
CSS-Tricks started on Chris's love for CSS. But it was not intended as a business. It's only when advertisers reached out to him that he realized he could make something out of it. It grew slowly but surely, and steadily enough to become an important part of his story and business. In September 2012, he decided to double down on CSS-Tricks, make a full redesign of the site with designers and illustrators, and of course, do this in the open. He created a Kickstarter and then tons of blog posts and videos sharing the process.
In December 2021, Chris launched CodePen, and just before that, the Talk-Shop Podcast. Since then, those have been his 3 main activities... and he doesn't seem to miss the serial-creative process.
For Chris, a good day starts feeling good and rested, then has a good couple hours without structure, a few productive meetings, and some good writing time. And, of course, ends with the family.

Advice:

Grant other people self-reflection. Software Development is much more diverse than one thinks. If you don't like Python, design, or maybe low-level data manipulations, all those are entirely different. Not liking the ones you have seen so far doesn't imply you are not a software developer.

Quotes:

"It was computer work, and it was on Macs, so I didn't hate it"
"I like having a buffer between the client and me"

Thanks, Chris, for sharing your story with us!

.ltag__user__id__2545 .follow-action-button { background-color: #080E3B !important; color: #ffffff !important; border-color: #080E3B !important; }

Chris Coyier

Writing at [CSS-Tricks](https://css-tricks.com), podcasting at [ShopTalk](https://shoptalkshow.com), co-founder of [CodePen](https://codepen.io).

You can find the full episode and the show notes on devjourney.info or directly here on DEV

Did you listen to his story?

What did you learn?
What are your personal takeaways?
What did you find particularly interesting?

Ryan Bergman loves terrible code... and other things I learned recording his DevJourney (#150)

Tim Bourguignon 🇪🇺🇫🇷🇩🇪 — Tue, 11 May 2021 07:34:22 +0000

This week, I published Ryan Bergman's #DevJourney story on my eponym Podcast: Software developer's Journey. Among many other things, here are my main personal takeaways:

Ryan's journey started with a TI-99, and all you could do with it was to program it. Learning to code in involved type-in-programs from the Byte Magazine and saving programs on cassette tapes.
Bryan fought his way through high school with what he later recognized as ADHD and dyscalculia. Because of this, Bryan developed a real love-hate relationship with anything maths-related. So he ended up becoming a "total art nerd" (sic). He briefly studied graphic design in college before dropping out. He joined the National Guard, drifted for a few years, and finally returned to college, changing his major to city-planning, a.k.a. SimCity in Real-Life.
When he was about to reach the job market as a junior city planner, he doubled back as a graphic designer. During his university time, he had learned some HTML, so he found a position as a front-end graphic designer in a dotcom tech startup doing Newsletters/eZines (before they were cool).
In his next job, Ryan worked on a learning management system and discovered a learning culture, which literally changed his career path. He worked with Coldfusion and discovered pair & mob programming and automated testing. But most of all, he had to maintain software written by "real programmers." They had produced awful code, and it took him a while to realize that he himself was not in the wrong. It took him a long time to get rid of his imposter syndrome. Following this rewrite, the company experienced a re-org and asked the help of a few XP and Agile consultants. The company really embraced this movement and became a recognized Agile force in the De Moine area.
"We watched in amazement how the contractors, who didn't know the domain, make all the same mistakes we had made for so long before them." Letting a new team rewrite a new software will invariably result in some surprises like this. Ask me how I know 😅
Ryan then joined JohnDeer, and the breadth of the domain has kept him there since. There are so many challenges to solve.
Ryan joined the "larger agile community" in about 2010. He now calls it "his family." He loves to be with like-minded individuals who cherish the original idea of agility, like the coaches he met a decade earlier and from whom he learned XP. Talking about conferences, Ryan dropped this sentence: "The sessions are a way to get interesting people to conferences so that I can talk to them for free." I couldn't agree more. The "hallway track" is the best!

Advice

Find your thing, be curious about it, and don't expect anyone to dig for you

Quotes:

"When Javascript came out, I thought 'nah, who needs that'... I still feel like that though"
"I don't hate Perl; I hate other people's Perl. But my Perl is perfectly fine, and there is nothing wrong with it, and it is completely readable."
"Agility has a bad reputation nowadays, mostly because of all those agile consultants trying to sell you big agile transformations"
"The sessions are a way to get interesting people to conferences so that I can talk to them for free"

Thanks, Ryan, for sharing your story with us!

You can find the full episode and the show notes on devjourney.info or directly here on DEV

Did you listen to his story?

What did you learn?
What are your personal takeaways?
What did you find particularly interesting?

Leticia Portella started with MATHLABianesque Python... and other things I learned recording her DevJourney (#149)

Tim Bourguignon 🇪🇺🇫🇷🇩🇪 — Thu, 06 May 2021 14:22:16 +0000

This week, I published Leticia Portella's #DevJourney story on my eponym Podcast: Software developer's Journey. Among many other things, here are my main personal takeaways:

Leticia's story starts in oceanography, where she mostly did data analysis in MATLAB. During an internship, she was asked, "why do you use MATLAB?" Her answer was along the lines of "because that's what I know." And then, she was introduced to Python. Her colleagues started giving her challenges like "how would you do this in 2 lines of code?" And that's how she "fell in love with Python programming" (sic). But it took another job, a task waiting to be automated and save her days of work (4 days -> 15 min), and her boss being on vacation for the news to really sink in: she was a developer!
When a Python meetup was created in her city, Leticia went in once, discovered a room full of men talking about web development with Python. She didn't understand a word. She didn't feel welcome or included. She left with the clear intention of never coming back. A couple of meetups went by until one of the organizers asked someone to hold a session on Numpy and reached out to Leticia, asking her to try again. When she showed up, the whole community went out of their way to make her feel welcome, show her gratitude for being there and suggested creating a PyLadies community. And they did. Leticia also co-organized Pycon-Brazil and finally decided to give her first talk. A project manager was in the room and offered her a job on the spot.
I asked Leticia to expand on the difference between Data-Analysis and Simulation. Both are very intertwined. Simulations are producing a lot of data, which needs making sense of. That's where Data-Analysis comes into play.
When she decided to learn Scala, Leticia decided to #LearnInPublic. She decided to write a blog post for each learning session to sediment her learnings. She said: "I like writing, I like sharing, and it makes me study better." And she also creates a lot of "cheat sheets" summarizing her learnings. And those are great to use later on as well when her brain has moved on!
Through the years, Leticia built a close-knit network of trusted friends & advisors but also found many mentors who went the extra mile to help her grow, were patient and loveable, who "never made her feel less, because she didn't know this or that". How awesome is that?
"As a mentee, you have to learn how to annoy people without them hating you" said, Leticia. She apparently rotates the people she asks questions to spread the load!
Leticia started a learning group with 4 women but found it hard to deal with the different momentums. On the other hand, she has one mentee "and she will cherish her forever."

Advice:

"Learn how to learn, everything else is transient"

Quotes:

"At first, my Python scripts were very MATHLABianesques" 🤣
"I have found a very nice spot for now, but my heart is with data, I cannot lie"
"I never stopped to study javascript, I learned it through the pain"
"Pressure on myself? Always!"
"As a mentee, you have to learn how to annoy people without them hating you"

Thanks, Leticia, for sharing your story with us!

You can find the full episode and the show notes on devjourney.info or directly here on DEV

Did you listen to her story?

What did you learn?
What are your personal takeaways?
What did you find particularly interesting?

Bryan Beecham cares about people... and other things I learned recording his DevJourney (#148)

Tim Bourguignon 🇪🇺🇫🇷🇩🇪 — Tue, 27 Apr 2021 09:36:27 +0000

This week, I published Bryan Beecham's #DevJourney story on my eponym Podcast: Software developer's Journey. Among many other things, here are my main personal takeaways:

Bryan's story started with a Commodore computer at the back of the classroom and the BASIC language. AS he puts it, "it was like magic." He was so hooked that in grade 8, he made a presentation in front of the board of education on the importance of computers for the future of education and "why the school needed more computers", and "how they were improving hand-eye coordination". Like many before him, type-in programs played a big role in his learning.
Bryan has been juggling with many languages, each time trying to build a new skillset. First BASIC, then VB, then C# with ASP, then Python. When I asked why Python, he responded "I like Python because of the explicitness of it; it's C# on easy mode." Bryan really likes to look at the business problem that has to be solved and find the right tool for the job.
Bryan has reached a very agreeable place of being able to say "no" to clients. It was a long road, paved with him organizing his work well. He juggled between work for his clients, work for/on himself, and networking/communities. Bryan then talked about organizing himself and especially losing what takes his time and doesn't bring joy and/or value.
Bryan talked for a while about behavioral skills (instead of soft skills) being at least equally as important as technical skills, for we have to interact with each other and not be jerks.
When Bryan first heard the term "Agile", he looked it up and realized that it was "how they had been working all along at his previous company." I love to hear those stories. Scrum and Agile didn't come out of anywhere. They were born as a crystallization of the best practices of that time.
Bryan changes his coaching stance depending on the team dynamics, the daily mood, and other factors. He can go from the sidelines and stand back all the way to player coaching, right at the keyboard. A lot of it has to do with "sensing the room."
Bryan gave us one of the most forming tips he ever received: "I used to believe the goal was for me to coach a team to the potential that I saw, but instead, the goal is to bring them where they want to go. It's not about me!" We then devised how managers should show "what" they want and empower the teams to do it fully. "When you do it well, it's all about the team being able to make the decisions."
Bryan finally spoke about coaching. He said "Everyone should have a coach, if you want to grow, you need a coach [...] you have to surround yourself with brilliant people." When I asked him why people don't get one, his response was instant: "ego!, they will have to say 'I don't know' a lot that is not weakness, that is strength. [...] it takes a lot of courage to approach things with a beginner's mind. If you approach things with the idea of not knowing anything, you are going to maximize your learnings"

Advice:

"Get a coach"
"Don't hang around with negative people. Surround yourself with people lifting you, and you will be amazed at what you are capable of."

Quotes:

"I like Python because of the explicitness of it; it's C# on easy mode."
"I forced myself to no use any additional libraries because I wanted to learn it the hard way"
"You have to be willing to put yourself out there, to say I don't know but I want to learn"
"Caring about the people is more important than caring about the project. If you care about the people, the project will take care of itself"
"I used to believe the goal was for me to coach a team to the potential that I saw, but instead, the goal is to bring them where they want to go. It's not about me!"
"Everyone should have a coach; if you want to grow, you need a coach"
"Your community is critical [...] you have to surround yourself with brilliant people"
"It takes a lot of courage to approach things with a beginner's mind. If you approach things with the idea of not knowing anything, you are going to maximize your learnings."

Thanks, Bryan, for sharing your story with us!

You can find the full episode and the show notes on devjourney.info or directly here on DEV

Did you listen to his story?

What did you learn?
What are your personal takeaways?
What did you find particularly interesting?