I've been having conversations with a really smart friend of mine (PhD in one of the sciences, and fairly good with programming) who decided to repurpose himself as a software guy, got a job a couple years ago at one of the tech giants (not the big four though).
Everytime I talk to him, he expresses annoyance that his team and lead are dogmatic about CS principles and want him to modify his programming practices. To give a few examples, he thinks being against using goto in C/C++ is dogmatic, and that there is no need to develop a testing framework until the software is developed, among a bunch of other things. All this while he piled on at the rate of about 1000 lines a month into the codebase (he started this project from scratch, surprise surprise).
I have been trying to convince him of the need to develop software engineering skills and that it's more about lessons learned from history than being dogmatic about anything.
Recently he started expressing interest in climbing the corporate ladder and becoming a manager or something. Good for him, I didn't point out anything, but to me, he felt
like one of those types who are more interested in their career bottomline than in developing good principles and practices of the work they do (something that disappointed me coming from him based on the person I knew for many years).
Just recently I heard he got awarded for the software he developed. (For context, the company is a tech giant but not mainly-software. I was very surprised to find out that they don't have an internal document or guide on coding conventions, hence a developer gets to do whatever he/she likes).
Point of the story? not much except that it's another data point supporting my cynicism towards short-termist and superficial attitude of majority of people, especially those involved in the corporate culture.
Because I can see where this is going. This guy would want to become some kind of manager as soon as he can, and hand over the development to someone else. If that someone else has good software engineering skills, he/she would be able to poke many holes in this codebase, and/or would be put in charge of fixing the bugs (likely due to bad quality and hasty implementation of the code). This will delay and slow down the progress of the project, because fixing those bugs would involve fixing the quality of the code through heavy refactoring, etc. And
then this same manager would get to claim "When I was developing, the project's pace was great, and now you guys have started slacking off and creating lots of bugs".
> he thinks being against using goto in C/C++ is dogmatic, and that there is no need to develop a testing framework until the software is developed
The important thing missing here - context. There are perfectly valid situations where your friend could be right.
> he felt like one of those types who are more interested in their career bottomline than in developing good principles and practices of the work they do (something that disappointed me coming from him based on the person I knew for many years).
Maybe he wants to become a manager with good developped principles?
Of course you know your friend much better than we do. It's hard for outsiders to judge the situation.
> There are perfectly valid situations where your friend could be right.
I didn't say he thinks banning goto is dogmatic (and I never heard him say that his team completely disallows any use of it). You could be against goto and still be okay with its occasional use.
He seemed to be of the opinion that there is no reason to be against goto in the first place, because he never felt goto's use hurting his productivity. (and his use of goto, the way he explained it, definitely was more complicated than the rare cases where I think you could let it slide, e.g., the way it's used in the linux kernel code to get to the bottom of a function in case of failure, etc).
And why should we be against goto in the first place? Unfortunately, you cannot answer this question in one sentence, or a paragraph. "Go To Statement Considered Harmful" is not a theorem that has a proof. You have to read about it, and ideally, you have to experience what spaghetti code feels like, and what a goto-free codebase feels like. If you're not willing to take such a dive, you would never find out the answer. And if you have opinions in favor of goto without taking such a dive, don't be surprised if I lower my opinion about you as a scientist/engineer.
> Maybe he wants to become a manager with good developped principles?
And call me a negative nancy but your chances of developing good practices have diminished if your bad coding practices are reinforced through internal awards and the like. And I have no doubt his contributions may have felt significant to the higher ups enough to decide this deserves an award. But only in the short term. If this code gives problems in the next quarter or something, do they go back and review if the hasty implementation in the last quarter and liberal use of goto had anything to do with it? Likely not if your company doesn't even have a coding-conventions document.
I think it's pretty simple to make the case for goto, or any construct, being harmful in a work environment. Code is ultimately social, and if your colleagues find it difficult to read or use, then by definition it is harmful.
For another example, I love functional programming, but my colleagues hate it. It is, by definition, harmful for me to use at work.
I've been having conversations with a really smart friend of mine (PhD in one of the sciences, and fairly good with programming) who decided to repurpose himself as a software guy, got a job a couple years ago at one of the tech giants (not the big four though).
Everytime I talk to him, he expresses annoyance that his team and lead are dogmatic about CS principles and want him to modify his programming practices. To give a few examples, he thinks being against using goto in C/C++ is dogmatic, and that there is no need to develop a testing framework until the software is developed, among a bunch of other things. All this while he piled on at the rate of about 1000 lines a month into the codebase (he started this project from scratch, surprise surprise).
I have been trying to convince him of the need to develop software engineering skills and that it's more about lessons learned from history than being dogmatic about anything.
Recently he started expressing interest in climbing the corporate ladder and becoming a manager or something. Good for him, I didn't point out anything, but to me, he felt like one of those types who are more interested in their career bottomline than in developing good principles and practices of the work they do (something that disappointed me coming from him based on the person I knew for many years).
Just recently I heard he got awarded for the software he developed. (For context, the company is a tech giant but not mainly-software. I was very surprised to find out that they don't have an internal document or guide on coding conventions, hence a developer gets to do whatever he/she likes).
Point of the story? not much except that it's another data point supporting my cynicism towards short-termist and superficial attitude of majority of people, especially those involved in the corporate culture.
Because I can see where this is going. This guy would want to become some kind of manager as soon as he can, and hand over the development to someone else. If that someone else has good software engineering skills, he/she would be able to poke many holes in this codebase, and/or would be put in charge of fixing the bugs (likely due to bad quality and hasty implementation of the code). This will delay and slow down the progress of the project, because fixing those bugs would involve fixing the quality of the code through heavy refactoring, etc. And then this same manager would get to claim "When I was developing, the project's pace was great, and now you guys have started slacking off and creating lots of bugs".