Skip to main content

Programming: It's about how interested you are.

Had this tweet show up in my feed this morning and I think it's worth an explicit mention.  Eric Evans talks a bit about Domain Driven Design, a topic he's also not coincidentally published a book on many years ago:
Something I've been encountering in my travels as a developer and leader of developers is the varying levels of motivation, confidence and enthusiasm my peers conduct themselves with.  At one point during his talk, Eric speaks about how a hypothetical carpenter spends more time talking about his output than he does how he might use any particular tool.
Eric also - in my opinion - correctly highlights that the best people in the industry tend to be master technologists.  They constantly have their head in the space and are naturally disposed to aspects of technology and how they work together.

Eric's talk covers a lot of different areas as he works his way around and into various definitions of DDD, but this one bit really resonated with me.
When I was younger, the point it became clear that computers and more specifically software were in my future was when I developed a healthy obsession with it.  I've worked - specifically in the past - with so many people who treat the programs they make as just a way to a paycheque.  Without casting any negativity towards wanting to earn a living, I feel like there's something self-defeating to being a software developer and treating it like something rote or mundane.

Last year I was invited by the NRC to help participate in coming up with ideas for a curriculum for students learning to be developers.  One thing many of us on the panel agreed on was that you have to be innately interested.
For a room full of leaders from different companies that don't work together to say the same thing, there has to be a mote of truth to the notion!

Enjoy the video and I hope you're encouraged to start working on having a healthy obsession too!

Comments

Popular posts from this blog

Laravel is Good, Facades Aren't

I've been working on some Laravel 4 based packages lately which inevitably results in me also looking at other packages. I've noticed sometimes that people use facades at times that give me pause. The most troubling being from inside their model classes. A quick google turned up this video which assures people "there's still an instance behind everything, we're fine" .  Everything mentioned in the video is true except that there is a very glaring omission. Scope What usually goes out the door at the start of a long series of mishaps in software design is scope . When the desire to obtain a solution is stronger than the desire to consider the implications of a firm approach, mistakes are sure to follow.  Sacrifices like this are made due to the assumption of a high cost to developing carefully. What really is happening however is a false dilemma , being responded to with a convenience decision . It's very easy to write model code like ...

Building .NET Core Nuget Packages

My last blog post was on building and publishing npm packages, specifically for typescript projects. In my opinion, packages are an important fundamental unit in software development. They sit at the confluence of technical competence and collaboration, and represent something the software community should be proud of. Most of the time, you're going to be creating software packages once you're comfortable with some essential pillars: Coding Project structure Software architecture Building Delivery Community Licensing After I got my npm package up and running, my next task was to do the same thing with my C# libraries. Similar to protoculture, I have made a library called praxis .  This is done by leveraging the services and tooling known in the .NET ecosystem as nuget. In this case, praxis abstracts many of the concepts and functionality I require when producing server projects. It builds on top of ASP.NET Core, so in that sense you can almost think of it as ...

ASP.net Core 1 Projects on .NET Core 2

A small post for today although something I think could trip others up.  I'm trying out the latest WebJobs 3.0 beta which is a port of the 2.0 version with .net Core 2.0 support.  This is really exciting as .net Core projects are considerably easier to work with than .net 4.x.  There tends to be less magic and they're a lot more command line friendly. One issue is that in order to use the new WebJobs 3.0 library, my current ASP.net Core 1.x web applications need to be running on .net Core 2 to use it for dispatch.  This hasn't been too much of a hassle, it was largely just a matter of updating the TargetFramework entry in my csproj to netcoreapp2.0 .  You may also end up with a few other items to clean up after that as the netcoreapp2.0 TFM comes with some useful configurations out of the box to ensure well behaved .net 4.6 PCLs are easier to get into your projects. The one surprise I hit was that when I shipped things up to Azure App Service, I got a fairl...