One warning sign I look for when working with other developers is fear of breaking the code. The absolute worst systems I've worked on are the ones where the developers practically tiptoe around the source code.
Hi Jeff,
this is a very strong reminder for me to finally pick up a decent source code control system and start using it. Iām considering it for some time now, but as weāre not using it at work Iām really on my own here in finding out which one best suites me. It should be something you can easily use on your own, without too many server hassles. The best thing would be some clientside system, as I wouldnāt be able to convince other to install something on the network or spare server. I guess the best thing is just to give it a go and maybe in the end I can persuade others to go alongā¦ thanks!
Yes, you definitely have the right idea-- you want to be under source control at all times!
Ned Batchelder has a few recent posts on source control that you might find interesting:
http://www.nedbatchelder.com/blog
Read the comments on those posts for more reader suggestions, too. For me, IDE integration is a key requirement.
I agree completely. The best way to learn is by breaking things and then fixing them. And even if you donāt āknow the code from front to backā, the only effective way to get there is by slowly breaking and fixing things, IMO.
I think itās not really about being afraid to edit code itās the idea some people have that the code is gold. You see that a lot in c++ and not so much in Java/c#. I find some people write code like it will last forever, Its like a baby that they have to cradle to sleep every night. I think thats a mistake. I have seen the most bizarre standards that require so much labor and in the end you get this legacy junk. Code should be thought of as disposable. I like it quick and short with small chunks. I also hate emphasis on consistancy. Some people would rather do something consistantly wrong ( or leave bugs in )than to try and address the fundamental flaw! which requires going deep.
No matter how good you are the second time you write it itās almost always better. Usually any developer of almost equal skill can improve on anything the second time. If you have a piece of code which is so complex that you canāt re-write it without entering bugs then that is the best reason for doing so because the design is shit.
You get that a lot when you have massive classes or even methods with a million lines. You gotta chunk it up so that you can throw it out easier. just my 2c.
I agree with some of the conformity to standards issue, but not all. Some consistancy in coding standards, especially when working with teams, makes maintenance much easier. Note that Iām only really addressing coding and convention standards here. For instance, all variables on a program should follow an agreed-upon naming convention. Code for initialization, public methods, private methods, etc. should all be contained within regions. These kind of restrictions donāt place too harsh of an onus upon the developers, but digging up where someone elseās code is doing something strange is lot easier (or your code, because more than a couple of days after you wrote it, you start to wonder if you were drinking when you wrote it, or should start drinking before you continue).
In my opinion this type of person, who is afraid of breaking the code, is really afraid of learning the code. If you know the code front to back, or are confident that you could if you had to, breaking the code is not a big deal. It can always be fixed. If you donāt think you have what it takes to dig into the code and learn how it does what it does, of course youāll be afraid to change anything.
The controlled destruction is an amazing thing. Once I looked in to the state of code, I found itās really scary and unable ot maintain more. There were a design and this design was broken according to everyoneās convenience and made it hard to understand or work well. Even if we fix the issues, the other issues started popping up.
It was a kind of determination to remove the Junk code or break the existing code. Lot of functionalities which is fixed upon may break but that weāve to take care. But In the last 1-2 years, It was amazing experience of controlled destruction and it got succeeded!
I have a sticky note over my desk that says, āIf you break it, you will learn.ā Itās a philosophy one of my favorite (fearless) colleagues follows, and the sticky serves as a reminder and prompt to be just as fearless.
āIf you want truly to understand something, try to change it.ā ā Kurt Lewin
A decent set of tests can help reduce the fear. If you donāt have tests, start the learning exercise by writing some. Or is that cheating?
100% agree in theory and in practice. However, I work in an enterprise where my boss^4 recently told a Global Town Hall meeting that reducing risk is our #1 priority. Now, Iām experienced enough to understand that properly breaking things in development reduces the risk of improperly breaking things in production. But how do we keep junior developers from responding to the risk reduction imperative by shitting their pants any time something (that they didnāt even check in) doesnāt compile?
Hi Jeff. First post ever. Lets say you are new to the team, have an outsider view and questions about the code, receive confirmation that the code in development is just sick from team members coming and going and generally not knowing what they were doing, and you start making incremental refactoring changes that you know will work and is unit tested but when itās ready to check in and you did the code review with the lead he says itās too risky? I see this relevant because itās already broken so where does the fear come in other than I am new? Itās worth mentioning the lead is a legacy Oracle procedural programmer and doesnāt really care that much about the object oriented aspect of the application. The result was that the chief architect says it was garbage and the only choice since the lead has fears is that I have to create a completely new API but this goes against the ego-less principles of not trying to be a lone enforcer and we donāt seem to operate like a effective team. It feels like a lose lose situation to me and I feel like I need to switch jobs since I canāt get on any other project, any suggestions?
Iād say you should be lobbying for unit testing, or some form of testing framework, so that people can make changes. Is the lead programmer resisting the addition of tests?
The lead isnāt resisting unit testing, his feeling is that he really doesnāt care. I am going to do my best to lobby unit testing and when I first joined I actually pointed out they had around 80 to 100 integration tests, not unit tests, and they didnāt know how to setup a UOW with EF (I actually was interested in Dapper and created a POC but the knowledge base for the EF ORD was already there). So I setup a UOW with mocked data and showed them what they were missing out on but then the interpretation was that I was trying to prove myself (I just lolād at that point). So at the moment I am getting the chief architect and other seniors sign offās, and hopefully this will take off. Thanks for the advice and keep up the good work on the blog!
Iām a huge fan btw. Stack overflow is the greatest collective intelligence platform ever!