Underrated skill as a developer

What do you think is an important skill to have when in a role or wanting to be in a position that requires making decisions around software architecture and design? There was a phase in the middle of my career that changed my point of view. I'd like to explain what is an underrated skill that I credit for making various technical decisions, including those around architecture and design.
🔗 EventStoreDB
eventsto.re/codeopinion
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
/ codeopinion
✔️ Join via KZbin
/ @codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo...
0:00 Intro
0:43 Budget
2:30 Time
4:08 Technical Debt
#softwarearchitecture #softwaredesign
Answer Png vectors by Lovepik.com
lovepik.com/images/png-answer...

[@CodeOpinion]

What do you think is an underrated skill as a developer?

[@carstenkampe]

Knowing when enough is enough and to walk away from a problem or if approaching a problem one way is taking to long to spend the time to come up with another solution

[@vivekkaushik9508]

Communication? I find that most people don't know how to articulate their ideas effectively. They would 20 sentences just to make a single point. Such a waste of time and energy. Hour long meetings with almost no conclusions.

[@stevenstone307]

People skills. It's amazing how many devs I've met that don't know how to effectively communicate and handle working in a team

[@istovall2624]

embracing criticism as areas to improve, instead of cracks or faults.

[@everydreamai]

Coming in before watching I was going to say 1. Communication 2. Estimation. The later has a lot of facets and can take experience, and both are related. Great video.

[@marna_li]

I think that a lot of developers divorced from the business side which deals with value and cost. They are just used to do tasks and not seeing the goal or value in what they produce. At least that is what I have experience where I have been. "It is just a job to be done". Not everyone has has opportunity to get invested in what they build.

[@CodeOpinion]

Yup, your context/situation dictates how involved and aware you are of the value of what you're producing.

[@georgehelyar]

You shouldn't choose tech without costing it, but something that I find is that the cost of dev time is often completely ignored even though it is often orders of magnitude more expensive than the tech. e.g saving 1k a month on a particular database but then spending 20k a month on the extra dev time it takes to work with that database. A good exercise is to try to estimate how much one sprint costs in terms of dev pay for your team. It will probably be more than you think.

[@tremblben]

Devs should spend more time trying to understand the business just like we also have to make the business more aware of our own challenge and the impact. If you have a really short deadlines, you are going to cut corners. That technical debts will cause issues and very often do not get addressed so you also have to consider is it better shipping late or shit (it depends). It's just the nature of business, they don't care about what they don't see. Technical debts only become visible in form of bugs, performance issues, downtime and they will ask you to address them. But they won't ever ask you to refactor or write tests. They will ask for quick fixes. It's very easy to underestimate the impact on lost of revenue or productivity caused by technical debt. Great video love it!

[@madhattersc4051]

Value. The key word which is repeated over and over. Value is what the user, or client, receives from the solution. Monoliths can be great if it fits the value. Distributed architecture can also be great if it delivers value. Value is what is important to the client. If the client doesn’t feel that value is attained, then there goes the client.

[@CodeOpinion]

👍

[@robbiecheng4795]

I ran a business before getting into software development. I have done lots of budgeting but I don't get a pay rise because of this. In fact, I don't even get involved in any budgeting

[@DevLeader]

@codeopinion thanks for the Twitter exchange on this topic! Glad you got the video up, and it's excellent 💪 Aside from just trying to get folks past their initial hurdles to start writing code, I'm very interested in trying to help educate newer/junior software engineers on all of these other important skills that are totally separate from just "writing code". Seems to get no focus with this coding bootcamp culture. You have a much much much larger reach 😂 I feel like you could offer a lot of value to more junior folks if you could share about this. Otherwise, I'm happy to keep fighting the good fight 😁 But it'll be about 6 years before people discover my content I'm sure. That's 6 years of missed opportunity to help the next waves of software engineers!! Thanks again for this. Architecture is awesome, but grounding ourselves in the actual constraints that come with a *real* business are awesome too.

[@carstenkampe]

I really enjoyed this video. While I know technical videos are helpful towards guiding to a specific goal. I think providing more knowledge like this that are habits and behavioral patterns on approaching problems are much more beneficial than perhaps sharing specific industry knowledge since like you said context is king.

[@CodeOpinion]

Thanks for the feedback!

[@michalis2942]

Great video

[@shubitoxX]

Assuming debt will or can be paid back is quite optimistic and often those having to deal with the debt are not those creating it so there is a lack of feedback, awareness and care. Also optimistic is finding the person that can still make sense of all the mess others created. You're more likely to find those that claim to know it all and dazzle to pretend having a clue.

[@CodeOpinion]

I don't think it's optimistic at all. If you're in a position to and explicitly make a decision to take on technical debt, then you should likely also be in the position to be able to pay it back. If you're dealing with the technical debt of others and have no authority to pay it back, well that's a different context. Again, you're role/position in decision making matters. You mentioned "making sense of all the mess others created". I don't think we have the same definition of technical debt.

[@romanlunin386]

Totally agree, developers are not usually involved in company problems so it's easy to lost the sense of responsibility.

[@GnomeEU]

The most lacking skill would be social skills, sales skills and leadership. And when I look at other devs it's also passion. I think most devs are lazy by nature. It's rare that I overengineer anything. But if my boss or client doesn't give me enough time I will be stressed out and the result will be bad. I don't know devs that would drag out 4 hour tasks to a week unless you hate your job. I think that project managers often don't know the inside of the projects and how bad some stuff needs to be refactored. So they often get the feeling that devs don't know how to budget?

[@Munchopen]

Well... There is really more to it than this. For instance, you cannot keep a team of developers and recruit beginners if you don't give them the time to explore technologies they don't need, software design patterns that they don't need, new programming languages that they don't need etc... And I completely disagree with the notion of technical debt being a conscious choice. It would be nice if it was, because then I could always write the debt onto a backlog of sorts to actually consider it as debt. However, the truth of the matter is, that most developers including really skilled ones don't know when they are actually in the process of creating technical debt, because mostly it cannot be determined before after the fact and often even further down the road. Whether a piece of software or just a piece of code has become technical debt depends on the where the future is going. And last I checked the future was not here yet. I agree that some technical debt can be viewed up front, for instance if it includes a programmers known bad practice. In that case, talking about debt is ridiculous, since the programmer just isn't doing his or her job well enough. That's not debt, that's just bad programming. Sure. Bad programming becomes technical debt, but really it's more like bad design becomes technical debt because it's hard to get rid of it.

[@CodeOpinion]

Agree to disagree on some points! And that's all good, I appreciate your perspective. The technical debt on being a conscious choice is one I know not many subscribe to because there's so much we do without knowing were doing it. As for putting it into a "backlog" also indicates we have different ways of working.

[@johannormen]

The business case will tell you what tech is needed. Sadly many organizations stil have ops teams, enterprise teams that force devs to build Business case arround fixed infra or a plattform locked decisions. And there is to common the organization is split in two. Business and IT. business perform push where tech dudes never get a chance to know the business goals. And business that do not understand why its important to see both part as the business. So mostly people can't take decisions related to budget when they are not part of it. And outcome... that area is still a joke in many companies. Few focus on outcomes:/ its push push, feature factory way of working. The skill of budget is good but a rare skill to master when you are not part of the business. :(

[@FlaviusAspra]

I think you put too much emphasis on "business thinking in order to avoid over-engineering". Business thinking means more, and in the context of software architecture it means "thinking in terms of use cases". I've seen so many complicated approaches just because the coders wanted to abstract everything and through the plethora of abstractions they lost track of the actual use of the code, ie the semantic context. Once you loose that semantic context, you start to bend backwards out of necessity in the design, just to get back to pieces of information from that context you lost. In reality, this is a self-inflicted problem. If instead you put the use case at the front door of your system, then everything else gets easy. And this can be as easy as just that: make a directory/package called "UseCases", and for each kind of semantically different entry into your system, make a new use case class.

[@whatgoglikeno6120]

Most underrated skill is realizing that there are no consequences at work for 95-99% of people. There are no deadlines, there is no budget, there is no "we are so busy", none of it matters. If someone tells you to get something done till wednesday and its not done, nothing happens. You still get your salary, so does your boss, so does his boss, so does his boss. The sad, sad, traumatized user that really needed that thing on wednesday is just some other guy, working an office job that does not really care. He is not affected, he gets his salary, he will find other things to do with his work time. If you cause the project to run over budget and get cancelled, nothing happens. You just get put on another project. If the entire company goes bankrupt, nothing actually happens in the world. You just get another job and so do all your colleagues.

[@PbPomper]

I strongly disagree with this. You assume employees or programmers are selfish assholes wihtout any sense of pride and/or responisbility to deliver. Maybe I'm just lucky to work in a company where people care about what they do and they don't just do it for the money. But this has been my experience in previous work environments as well. Sure, there are so people counting down the clock everyday, but from my experience they are a small minority.

[@hellsregect]

If you care about your career then it absolutely does matter. Good luck getting a promotion or raise when every project you've worked on has been over time and underdelivered. Its a shame that software development is full of people like you that aren't professional and only turn up to colect a paycheque

[@bunnihilator]

Is your discord for paying members only?

[@CodeOpinion]

Yes. www.patreon.com/codeopinion

[@airjuri]

I'm just glad that i don't have to think about budget, i just write code that is required and get paid boom! No matter how much i think and do coding in my dreams, only the hours i actually code matters for some reason. And by the way, if you code just for money, you're not doing it right. Oh, developer, yeah, sounds like architect. Nothing to do with programming. ;)

[@user-qr4jf4tv2x]

apparently we always over engineer.. even stuff like task bloaters are annoying

[@Pekz00r]

I don't think budgeting or costs are that important. What is way more important is what value you are creating. If you are creating a lot of value the cost is not that relevant within reason. If you make sure you are always working on the thing that creates the most value you should be fine in the vast majority of cases.

[@CodeOpinion]

I agree, in theory. Developers understanding the value means they need to understand the domain they are in and the problem and solution space they are in. I advocate for this, 100%. I would say that understanding the value you'll inherently understand the cost.

[@snapman218]

You can't just finish a task by magically shortening the time. That's a lie. Part of software is closer to R and D, and if you confuse that with easy math widget making, you're going to be set up for failure. Of course business people who get paid by yelling at devs for things they don't understand is too big of an issue to point out, because they don't want them to look stupid.

[@Aalii6]

👍👍