Several weeks ago, I was talking to a programmer and we got into a discussion about the importance of software architecture. I maintained that having a defined architecture is important regardless of the team size, the person I was talking to asserted that architecture wasn’t necessary when there was just one person involved.
But here’s the thing. All software has an architecture. Even the most junior of programmers has an idea of how code should fit together. At issue isn’t really about architecture. It is about having a defined architecture, based on experience and best practices, that will allow the team to develop the software in question as efficiently as possible. Software architecture, at its core, says, “this is how we build software.”
To find the reasons why software architecture matters, it is helpful to think about what happens when there isn’t any defined architecture in place. For the purposes of this article, I’m going to generalize on how architecture impacts teams and where appropriate show why that is also important when your team is just you.
Over the past week, I’ve listened to and read several articles that have started me thinking more about the Psychology of Programming.
Not that I haven’t been thinking about this for a while. I’ve been quite intrigued by human behavior for a while now. But more recently, there was this podcast over on dotNetRocks about “Punishment Driven Development”. And this comment:
The happiest people in my experience are those that have options. They have transferable skills, see their employment as a personal choice, have self confidence that they are providing value to the company and are in a position professionally and personally where they could change job if they needed. The feeling of being trapped in a position from which you can’t escape (either a dissatisfying job, bad manager or whatever) will lead to negativity.
Which I almost agree with, except I think it is the negativity that leads to feeling trapped.
This past week, while working on a new project, I discovered some secrets to styling Angular2 that I don’t think are very well known.
There are two specific issues I needed to solve this week that took a bit of digging. The first was that I wanted my routes to fade in and out as I move between routes. The second was that I was using a grid control from a third party and I needed to style an inner component. We will cover both as well as some more basic operations.
I’ve been studying topics related to social science recently and one item that keeps popping up in various places is the idea of luck. It turns out that lucky people aren’t really all that lucky. There life has been arranged either by them directly or indirectly by their environment so they end up having more chances of good things happening to them.
So, how can we apply this to programming? How can you be a lucky programmer?