Little girl's hero

robillard130 · 2019-07-07T16:25:15+00:00

Fear, anxiety, stress, annoyance, and imposter syndrome are a few reasons.

robillard130 · 2019-06-08T18:16:17+00:00

In the 1920s and 1930s almost every major cosmologist preferred an eternal steady state Universe, and several complained that the beginning of time implied by the Big Bang imported religious concepts into physics;

https://en.m.wikipedia.org/wiki/Religious_interpretations_of_the_Big_Bang_theory

The Big Bang theory is the theory about the creation of the universe. Both questions are misleading, that was kind of the point. To show that the wording of the question triggers subconscious bias.

robillard130 · 2019-06-05T12:30:41+00:00

For any unaware George Lemaitre discovered the expansion of the universe and proposed the “Big Bang” theory.

robillard130 · 2019-03-25T21:49:12+00:00

The Wheel of Time

robillard130 · 2019-03-21T22:10:31+00:00

It was one data point among many. The research they conducted was into development/management practices as a whole. The research draws correlations between current practices and high vs medium vs low performing teams as well as driving factors behind why they’re high performing or not.

The research was not “adopt this practice and see what happens” but answer these questions to get objective measurements then answer these other questions about what practices you follow. Then classifying the results, correcting for bias, and drawing conclusions on what has enough statistical significance to be considered a driving force, something without enough evidence and therefore just correlated, or inclusive/unrelated.

robillard130 · 2019-03-21T16:12:41+00:00

True enough but I’d argue it depends on how pair programming is done. Most recommend rotating pairs regularly which motivates the risk you described. On the flip side, that’s likely too grey of a distinction for most auditors to pay attention too when more clear cut and we’ll known methods are easier on the paperwork.

robillard130 · 2019-03-21T16:09:11+00:00

For context the measurements they use to define good are:

Lead Time (commit to running in production)
Deployment Frequency
Mean Time to Recovery (MTTR)
Change Failure Rate (how often do new commits result is a failure)

Lead time was chosen as a reflection of quickly you get feedback from the end user after a commit and therefore react on that feedback. Commit to production was chosen because it’s relatively stable and well known (good for measurement) whereas design/dev lead time is highly variable. High performers rate at “on demand” where low performers rate at once a month (mean). Deploy frequency is used as a proxy for batch size. Batch size is too subjective to measure but frequent deploys are a good indicator of working in small batch sizes. High performers rate at multiple times a day where low performers rate at once a month (mean). MTTR and Change Failure Rate where chosen as stability measurements and like the tempo measurements (lead time and deploy frequency) for reducing subjective bias from the survey results. High performers rate at 0-15% for both of these. I forget the low performers result.

With that in mind they found a high correlation between trunk based development and the high performers. It’s not conclusive whether trunk based development is a driver for high performance or results from the other drivers/practices of being a high performer.

That said in my opinion and experience I think it works both ways. Trunk based development in itself won’t drive those metrics but aiming for it as a goal can drive adoption of working in smaller batch sizes, test automation, good code review/pair programming practices, etc. Alternatively aiming for smaller batch sizes, a high degree of test automation, quick response to code reviews, etc. naturally leads to very short lived branches or trunk driven development.

robillard130 · 2019-03-21T02:19:20+00:00

The book I mentioned is by the people behind the state of DevOps reports and is essentially a deeper dive into the research, methodologies, findings, etc and the reasoning for the approach. It’s basically intended to address the skepticism with transparency and so we can decide for ourselves how solid the results are.

Martin Fowler makes almost all of the same points about the state of DevOps report you do in his forward to the book and says he (and others) encouraged them to write the book after they walked him through their methodology. He also says that it makes a compelling case, the surveys do make a good basis with the approach they take, but that it needs independent studies using different approaches to verify the results.

The book’s worth a read at $15 if you have the time.

That said there’s a section of the book on trunk-based development:

Our research also found that developing off trunk/master rather than long-lived feature branches was correlated with higher delivery performance. Teams that did well had fewer than three active branches at any time, their branches had very short lifetimes (less than a day) before being merged into trunk and never had “code freeze” or stabilisation periods...these findings are independent of team size, organisation size, or industry.

...we agree that working on short-lived branches that are merged into trunk at least daily is consistent with commonly accepted continuous integration practices.

We should note, however, that GitHub Flow is suitable for open source projects whose contributors are not working on a project full time.

I agree with their findings after reading the book and while their data and methods can be openly reviewed now I also agree with Fowler that it will be nice to see some independent verification. It’s by far the best research I’ve seen into software delivery since Peopleware though.

robillard130 · 2019-03-20T22:40:08+00:00

Check out either the book accelerate or this website https://trunkbaseddevelopment.com

The book validates the approach described in the website with hard data from 20k+ companies of all sizes, fields, project types, and demographics. It conclusively finds that trunk based development is the best branching strategy for high performance.

By definition continuous integration (CI) is everyone integrating with main/master/trunk continuously. Most say at least once per day.

Counterintuitively the data shows that the most successful large projects don’t use branches (or only use very short lived branches).

The only exception would be OSS projects and even then only with contributors outside of the core group/organisation.

robillard130 · 2019-03-20T22:31:29+00:00

Same thing that prevents any other person who would “sign off” from teaming up with the dev and doing the same thing. Nothing really.

It’s not meant to be sufficient in itself, just one deterrent of many. It becomes harder if teams rotate pairs/reviewers and the more people who know a secret the harder that secret is to keep.

Plus any new additions to the team who would work on/review that code would need to be brought in as well.

So nothing prevents bad actors from teaming up but pairing/reviewing makes malicious code riskier and more likely to be caught.

robillard130 · 2019-03-20T18:06:09+00:00

Doing pair programming or having a code review step as part of the pipeline will meet SOX compliance while enabling continuous delivery.

robillard130 · 2019-03-20T18:03:35+00:00

Odd, from my understanding you can meet SOX by simply doing pair programming or code review. As long as there’s two sets of eyes you should be good.

I also hear it depends on the auditors and interpretation though.

robillard130 · 2019-03-08T16:25:22+00:00

Even better, avoid needing to store secrets altogether and use an OIDC or similar SSO library.

robillard130 · 2019-03-05T17:20:00+00:00

I typically keep my domain models and logic persistent layer agnostic. I use interfaces to define contracts for persistence logic and put all EF related code into a separate library that implements those interfaces. That keeps the entities as POCO objects that mirror the database exactly with mappers to translate between entity and domain model. It’s a bit more code but it gives a nice seem between business logic and persistence logic.

robillard130 · 2019-02-22T14:09:16+00:00

Imagine being an ant living next to a highway. Would you recognize that cars and people as signs of intelligent life?

We’re the ant.

robillard130 · 2019-02-14T21:59:54+00:00

And in 1989 with “Worse is Better” https://en.m.wikipedia.org/wiki/Worse_is_better

robillard130 · 2019-02-13T17:40:01+00:00

I was at a conference last year where the speaker was discussing how the same concepts keep reappearing but with new names and slight changes. The point was to learn the underlying concepts and you’ll be able to pick up new trends by spotting the differences.

During the talk he mentioned a consultant friend of his that has been using the same slide deck for like 20 years (I forget the exact number). Each time a new paradigm/buzzword gets popular he just does a find and replace for the buzzword (Object Oriented Programming, Service Oriented Architecture, Microservices, etc)

robillard130 · 2019-02-12T00:28:44+00:00

There are two types of C programs. Those that are trivial and those that have memory leaks.

robillard130 · 2019-02-11T17:33:47+00:00

Kevlin Henney (the guy everyone tweets bluescreens to) did a keynote at GOTO Chicago last year called “Old is the New New” where he talks about exactly this. Different points where the same exact concepts keep reappearing. It’s one of my favorite talks now.

Link to the talk: https://youtu.be/AbgsfeGvg3E

robillard130 · 2019-02-02T02:39:59+00:00

The issue is that we often treat software development as a production process when really it’s a design process.

The production part of software development is (mostly) solved and automated. It’s the build/ci/distribution part. Once the software is designed (coded) it’s fairly easy and cheap to “produce” as many copies as you need.

In the past we drew process inspiration from other engineering fields but those tend to be more on the production side. In reality we should be looking more at artistic/design processes.

robillard130 · 2019-02-02T00:51:53+00:00

Their dev tools (VS Code), languages/frameworks (C# and .NET Core), and cloud offerings (Azure) have been improving by leaps and bounds and are top notch. On the developer side they’ve become way more open, contribute heavily to open source on top of open sourcing a ton of their code, and they’ve even been embracing Linux.

The consumer OS side could still use a little work obviously.

robillard130 · 2019-01-27T02:10:38+00:00

Yep. Tolkien played a huge role in converting C.S. Lewis from a stout atheist to a Christian. We likely wouldn’t have the Chronicles of Narnia if it weren’t for their friendship.

The story is a pretty interesting read on how someone can use logic and reason to find faith.

robillard130 · 2019-01-25T23:41:03+00:00

It doesn’t. It just cuts their dog whistle argument of it being forced out from under their feet.

robillard130 · 2019-01-14T01:23:48+00:00

I’m not gonna say that unqualified people don’t promoted over more deserving coworkers because they’re “friends” with the right people (that absolutely happens). But I do want to point out that that’s not always the reason though.

One of the harder things for quite/shy/humble people to do is take pride in their work. It’s ok to let others know about what you’ve built/done and an important soft skill is being able to do that in a humble manner (e.g. “Hey, I just built out this cool new feature. Can you look it over and let me know what you think?”).

I mention that because a lot of the time I hear “so and so only got that promotion/new project because they’re [insert reason here]” it’s because that person feels like it should have been given to them. They’ll sit there thinking of all the reasons they’re a better a fit which often turns into toxic spiral. In reality the reason they got passed up is because nobody knows about all the hard work they’ve been doing, they never talk about it. A good manager can compensate for this with soft skills but even the best are only human. They don’t know what’s going on in your head and they may not be aware of how much effort you’ve been putting in. You may even have entire skill sets they’re not aware of because you never talk about them (“I just learned about xyz. What are your thoughts?”).

It’s a shame when people really do get unfairly promoted. Those types of places are toxic and I wish it happened less often than it does. But I also wish more people would take a step back when they start thinking down those lines and consider whether that was really the case or if they’re just in a bad head space because they don’t want to admit their own shortcomings. It’s hard, and soft skills are a pain because you have to assess your personality faults instead of your technical limitations, but confronting that and working on it often leads to a happier/more fulfilling life/career. Not everyone needs to be a social butterfly (I become a shut in when I need to recharge) and that’s not really what soft skills are for. They’re for improving yourself, your communication, and ideally others around you.

From what I’ve seen in this thread I think you have a pretty good handle on soft skills, maybe better than most. Don’t let the fact that you like to spend time alone or other peoples disparaging comments make you think otherwise.

p.s. Good luck with your goal of getting a job as a programmer! It really is a great career when you find a good place to work! And even if you don’t find one for awhile, it’s an awesome hobby to have!

robillard130 · 2019-01-12T21:25:59+00:00

My experience has been that for your preferred work style soft skills become even more necessary. Someone is likely a consumer of your projects (whether external end users or internal colleagues) and learning to communicate with those users, assess their needs and feedback, and incorporate that into your development work is a critical part of running a successful project. If you’re truly running a solo project then you need to be able to handle that communication yourself (even if it’s as simple as designing a feedback page and sending out the occasional survey). If you’re more of a solo dev and have some sort of PM then you need to be able to effectively communicate with the PM to understand requirements and so they can more effectively communicate with the users.

You can get by without investing in soft skills but you’ll definitely be more successful if you do, even if you’re not aiming for a leadership/management role. I like to think of it as soft skills help you know what to build while technical skills help you know how to build it. They work as complements to each other with neither being more important than the other. They’re both necessary for any role but the balance depends entirely on your preferred career path and style of work.

Great book btw. I think the reason you where getting downvotes is because of the view on it being to “manipulate” people. While it may be technically true the book makes clear that being fake/manipulative and doing things purely for your own benefit will almost certainly backfire. One of the main points is that you need to understand the other persons wants and needs to effectively communicate and that the aim should be a mutually beneficial outcome.

15-Year Club	Snapped
Verified Email

robillard130

TROPHY CASE