6 ms·

This article should be called 'Mastering large-scale team programming'. In reality there is no single correct approach to programming. All programmers/engineers

This article should be called 'Mastering large-scale team programming'. In reality there is no single correct approach to programming. All programmers/engineers/developers have different specializations. Some developers are really good at getting an MVP out the door quickly but their code may not quite work at scale. Others are good at working in large teams on large projects, others work better alone or in small teams. These different types will produce different types of code - the utility value of various programming habbits changes based on team size, project size and urgency requirements. There could be some 'Master MVP programmers' and 'Master team-player programmers', 'Master large-project programmers'... You can rarely put them all under a single label - As developers we tend to get stuck with particular styles depending on which kinds of companies we have worked for. It is not quite correct to assume that because a company is financially successful and handles many millions of users, that its methodologies are the only correct way to do things. Programming is an adaptive skill and should change based on economic/scale requirements.

phillipwills 10y ago
I wouldn't say that this article is describing a correct way to do things. It's more of a set of guidelines to follow, and I'm glad someone wrote them down. I've been doing these things, but I generally have a hard time concisely describing it. Of course, these aren't hard and fast rules. More of a guide to thinking about problems to help programmers be more efficient and accurate... More precise... I don't really know how to describe it, but one day, you find yourself doing these things more... Stuff gets easier... Things just start to click. I'd like to add one more, though maybe it's really just another way of putting one of the other statements. Stop worrying about all the unknowns in the project. Work on what's known, usually the unknowns will become more clear as you progress.
- LoSboccacc 10y ago
  yeah many are really important, like the part about 'calling your shot' - I constantly see so many people testing solutions to problem at random, either copy pasted from internet or built using random auto-completion; they spend days and days circling around without ever understanding the changes they're making nor the goal their building towards. It's doubly painful when days after they come up with the random set of lines that produces the intended result and dozen unintended side effects and proudly declare 'see! I did it' the fact is this stuff has been in literature from the seventies. I found very little in this article that couldn't be found in 'code complete' or 'refactorings'. I just wish at some point developers will stop learning everything from scratch.
- deleted 10y ago
  [deleted]
- dfraser992 10y ago
  I agree. They all seem quite familiar, though more abstractly defined than I would define them. Perhaps that is why I am now a bit tired of development - too many new specific details to learn about the 'latest and greatest', but fundamentally it is all the same stuff anymore. Maybe I'll pick up Haskell, just to think in Lisp-ish terms again... But statistics and ML in general are now drawing me in - and I hated stats in college. Brand new concepts. Like LoSboccacc said, all this stuff is in 'Code Complete' and the related series of books. Another I'd recommend is 'The Practical Guide to Structured System Design' and 'The Psychology of Computer Programming' (about egoless programming). Old books, but well written and perhaps seemingly basic considering how complex React/Node/javascript... seem to be, but the fundamentals never go out of fashion.
- jcbrand 10y ago
  > Stop worrying about all the unknowns in the project. Work on what's known, usually the unknowns will become more clear as you progress. Good advice which applies not only to software development. I've found that focusing on what's currently known and on what I can change removes anxiety, allows me to move forward and then usually the unknowns resolve themselves along the way.
  - mcguire 10y ago
    It works very well, until it doesn't. Then you have a pretty interface, an elegant test suite, and a big black box full of entropy and ignorance labeled "then a miracle occurs".
    - phillipwills 10y ago
      Even when that does happen... and I'd argue that it often does not, if you've done the work to make your interface pretty, and write a precise, accurate test suite, you've usually done the work to make the actual functions neat and orderly... Even when you end up with a black box full of entropy, it's segregated from the rest of the system. You can feel free to change the rest of the system around it and know that the black box will keep doing it's job, as long as you keep using the well-written API within spec. But, that's not all you get... because you took the time to write the tests, you can refactor this entropy box to your heart's content... until it starts looking more approachable. You've got your tests around the API, right? Then you don't even really need to change them to do the refactor work. The only reason to change the tests would be if you want the function to do something else (or you missed something, of course). Take small steps... refactor out a couple lines at a time... run the tests with each iteration. Based on previous experience, you're going to end up with a fairly clear and concise implementation... not to mention performant.
      - mcguire 10y ago
        Absolutely! Get something working and then keep it working while making small steps. On the other hand, the example that comes to mind is Ron Jeffries' TDD sudoku solver. I've seen several systems where the magic black box is doing things hilariously wrong---as long as it works on the test cases and the production results are sufficiently difficult to verify, it'll be accepted as gospel.
ObeyTheGuts 10y ago
Absolutely disagree with you, slicing problems to small and focusing one at a time and all other good points is a must if u want to be good at any kind of programming and even more even other skills outside programming.
- jondubois 10y ago
  Not if you have a hard deadline and your client is launching a massive advertising campaign for your product in a few hours. Also if your project is part of a promotional campaign, it will be up for a few months and then the whole thing will be torn down forever - You don't want to over-engineer it. I only worked briefly in the digital agency space, it wasn't my thing. My workflow very much adheres to the points described in the article but I wouldn't say that they necessarily reflect all that it means to be a 'Master programmer'.
  - Joeri 10y ago
    It seems highly unlikely that nothing would be reusable across campaigns. Identifying the commonalities and isolating them into subprojects that you build out in small increments would seem to be a benefit. In fact, I've been to a presentation by a digital agency on how they did exactly that and improved the time-to-launch on new projects as a result. Besides, you don't want to overengineer anything. Refactoring will happen, so the design can be deliberately minimal at the start if proper refactoring practices can be applied.
  - dasil003 10y ago
    If, by your original comment, you meant that if your project is simple enough you can muddle through like this, whereas with a large project you can't, I agree with you. But just because bad design doesn't scale up, does not mean that good design doesn't scale down. The bottom line is good design is fractal. You absolutely need it to achieve the largest scale, but it pays dividends at any scale. While it's true there are a lot of cases where it doesn't matter, doing so will never make you a master programmer any more than chainsawing a log to make seats around a fire pit will make you a master carpenter.
Teeboo 10y ago
All spoken brilliantly as someone who has not seen the nuance beyond the post. The Facebook note was written by Kent Beck, father of eXtreme Programming (XP) and original Agile manifesto signatory. He is not saying follow this methodology because a company made money. Invert your thinking; he is saying the majority of companies that utilise the following values and techniques have far fewer failed projects and deliver far more projects to scope, meeting customer requirements in a suitable timeframe. To say that this man needs to consider other approaches is akin to saying Muhammad Ali should have considered other boxing styles ;-)
- jondubois 10y ago
  Except we don't all do boxing and we aren't all Muhammad Ali. But some of us may be masters of our craft nonetheless. These 'guidelines' would mean very little to someone who programs microcontroller chips - Not saying these guidelines aren't useful, but in some environments there are more important aspects like will my program fit in flash memory? Do I have time to refactor this code or should I just patch it quickly and work on something more urgent/important?
  - AnimalMuppet 10y ago
    > These 'guidelines' would mean very little to someone who programs microcontroller chips I program embedded systems, which is pretty close. I still thought that the guidelines were spot on.
- plinkplonk 10y ago
  The man created a methodology [1]. That is wonderful but (imo) it doesn't give him the chops or credibility to tell other people how to program or solve problems. Think about it. Does Grady Booch (builder of yesterday's, now forgotten methodology) have some kind of special wisdom to dispense? If not why does Kent Beck? "Mastering" Programming, heh. That said, sure no one can argue against such 'motherhood and applepie' statements at such a high level of abstraction. Here is one from me "Think about what you do and act accordingly". you are saying "well duh?"? Exactly my reaction to this pablum. Not sure any of these aphorisms are particularly relevant in practical work. Still, whatever makes people happy. If you find these useful, good for you. [1] Not ignoring his work on JUnit which I used extensively when I used to work in Java. Of all the agile gurus, I respect Kent the most, because he has actually written useful code. Just playing devil's advocate a bit..
_pmf_ 10y ago
> This article should be called 'Mastering large-scale team programming'. To be fair, that IS the hard kind of programming. Small, focused teams of talented developers can do things pretty much as they like and are likely to have a positive outcome. (That's why I'm skeptical of typical "agile team" success stories; if you care enough about your job to identify with the methodology, you are probably a competent developer that would get results with mostly any methodology ... it's a self-fulfilling prophecy.)
- Teeboo 10y ago
  You are correct, it's just that we wrote down those behaviours and practices used by successful teams and they became the agile values. It's not self-fulfilling. It's fulfilling. The same way Doctors wrote down the treatments that worked for patients and it became medicine. https://www.youtube.com/watch?v=DHVVKAKWXcg https://www.youtube.com/watch?v=DHVVKAKWXcg
blub 10y ago
I have no idea what it should be called, but it is too abstract and short to get any use out of it. I'm not so sure about splitting developers into those types either. Sure, there are different personalities and specialisations out there, but... MVP programmer doesn't sound like one. It's too focused. But I fully agree that "Facebook" doesn't automatically mean success and good practices, just like "well known person" doesn't automatically mean being right.

phillipwills 10y ago

I wouldn't say that this article is describing a correct way to do things. It's more of a set of guidelines to follow, and I'm glad someone wrote them down. I've been doing these things, but I generally have a hard time concisely describing it. Of course, these aren't hard and fast rules. More of a guide to thinking about problems to help programmers be more efficient and accurate... More precise... I don't really know how to describe it, but one day, you find yourself doing these things more... Stuff gets easier... Things just start to click. I'd like to add one more, though maybe it's really just another way of putting one of the other statements. Stop worrying about all the unknowns in the project. Work on what's known, usually the unknowns will become more clear as you progress.

LoSboccacc 10y ago
yeah many are really important, like the part about 'calling your shot' - I constantly see so many people testing solutions to problem at random, either copy pasted from internet or built using random auto-completion; they spend days and days circling around without ever understanding the changes they're making nor the goal their building towards. It's doubly painful when days after they come up with the random set of lines that produces the intended result and dozen unintended side effects and proudly declare 'see! I did it' the fact is this stuff has been in literature from the seventies. I found very little in this article that couldn't be found in 'code complete' or 'refactorings'. I just wish at some point developers will stop learning everything from scratch.
deleted 10y ago
[deleted]
dfraser992 10y ago
I agree. They all seem quite familiar, though more abstractly defined than I would define them. Perhaps that is why I am now a bit tired of development - too many new specific details to learn about the 'latest and greatest', but fundamentally it is all the same stuff anymore. Maybe I'll pick up Haskell, just to think in Lisp-ish terms again... But statistics and ML in general are now drawing me in - and I hated stats in college. Brand new concepts. Like LoSboccacc said, all this stuff is in 'Code Complete' and the related series of books. Another I'd recommend is 'The Practical Guide to Structured System Design' and 'The Psychology of Computer Programming' (about egoless programming). Old books, but well written and perhaps seemingly basic considering how complex React/Node/javascript... seem to be, but the fundamentals never go out of fashion.
jcbrand 10y ago
> Stop worrying about all the unknowns in the project. Work on what's known, usually the unknowns will become more clear as you progress. Good advice which applies not only to software development. I've found that focusing on what's currently known and on what I can change removes anxiety, allows me to move forward and then usually the unknowns resolve themselves along the way.
- mcguire 10y ago
  It works very well, until it doesn't. Then you have a pretty interface, an elegant test suite, and a big black box full of entropy and ignorance labeled "then a miracle occurs".
  - phillipwills 10y ago
    Even when that does happen... and I'd argue that it often does not, if you've done the work to make your interface pretty, and write a precise, accurate test suite, you've usually done the work to make the actual functions neat and orderly... Even when you end up with a black box full of entropy, it's segregated from the rest of the system. You can feel free to change the rest of the system around it and know that the black box will keep doing it's job, as long as you keep using the well-written API within spec. But, that's not all you get... because you took the time to write the tests, you can refactor this entropy box to your heart's content... until it starts looking more approachable. You've got your tests around the API, right? Then you don't even really need to change them to do the refactor work. The only reason to change the tests would be if you want the function to do something else (or you missed something, of course). Take small steps... refactor out a couple lines at a time... run the tests with each iteration. Based on previous experience, you're going to end up with a fairly clear and concise implementation... not to mention performant.
    - mcguire 10y ago
      Absolutely! Get something working and then keep it working while making small steps. On the other hand, the example that comes to mind is Ron Jeffries' TDD sudoku solver. I've seen several systems where the magic black box is doing things hilariously wrong---as long as it works on the test cases and the production results are sufficiently difficult to verify, it'll be accepted as gospel.

ObeyTheGuts 10y ago

Absolutely disagree with you, slicing problems to small and focusing one at a time and all other good points is a must if u want to be good at any kind of programming and even more even other skills outside programming.

jondubois 10y ago
Not if you have a hard deadline and your client is launching a massive advertising campaign for your product in a few hours. Also if your project is part of a promotional campaign, it will be up for a few months and then the whole thing will be torn down forever - You don't want to over-engineer it. I only worked briefly in the digital agency space, it wasn't my thing. My workflow very much adheres to the points described in the article but I wouldn't say that they necessarily reflect all that it means to be a 'Master programmer'.
- Joeri 10y ago
  It seems highly unlikely that nothing would be reusable across campaigns. Identifying the commonalities and isolating them into subprojects that you build out in small increments would seem to be a benefit. In fact, I've been to a presentation by a digital agency on how they did exactly that and improved the time-to-launch on new projects as a result. Besides, you don't want to overengineer anything. Refactoring will happen, so the design can be deliberately minimal at the start if proper refactoring practices can be applied.
- dasil003 10y ago
  If, by your original comment, you meant that if your project is simple enough you can muddle through like this, whereas with a large project you can't, I agree with you. But just because bad design doesn't scale up, does not mean that good design doesn't scale down. The bottom line is good design is fractal. You absolutely need it to achieve the largest scale, but it pays dividends at any scale. While it's true there are a lot of cases where it doesn't matter, doing so will never make you a master programmer any more than chainsawing a log to make seats around a fire pit will make you a master carpenter.

Teeboo 10y ago

All spoken brilliantly as someone who has not seen the nuance beyond the post. The Facebook note was written by Kent Beck, father of eXtreme Programming (XP) and original Agile manifesto signatory. He is not saying follow this methodology because a company made money. Invert your thinking; he is saying the majority of companies that utilise the following values and techniques have far fewer failed projects and deliver far more projects to scope, meeting customer requirements in a suitable timeframe. To say that this man needs to consider other approaches is akin to saying Muhammad Ali should have considered other boxing styles ;-)

jondubois 10y ago
Except we don't all do boxing and we aren't all Muhammad Ali. But some of us may be masters of our craft nonetheless. These 'guidelines' would mean very little to someone who programs microcontroller chips - Not saying these guidelines aren't useful, but in some environments there are more important aspects like will my program fit in flash memory? Do I have time to refactor this code or should I just patch it quickly and work on something more urgent/important?
- AnimalMuppet 10y ago
  > These 'guidelines' would mean very little to someone who programs microcontroller chips I program embedded systems, which is pretty close. I still thought that the guidelines were spot on.
plinkplonk 10y ago
The man created a methodology [1]. That is wonderful but (imo) it doesn't give him the chops or credibility to tell other people how to program or solve problems. Think about it. Does Grady Booch (builder of yesterday's, now forgotten methodology) have some kind of special wisdom to dispense? If not why does Kent Beck? "Mastering" Programming, heh. That said, sure no one can argue against such 'motherhood and applepie' statements at such a high level of abstraction. Here is one from me "Think about what you do and act accordingly". you are saying "well duh?"? Exactly my reaction to this pablum. Not sure any of these aphorisms are particularly relevant in practical work. Still, whatever makes people happy. If you find these useful, good for you. [1] Not ignoring his work on JUnit which I used extensively when I used to work in Java. Of all the agile gurus, I respect Kent the most, because he has actually written useful code. Just playing devil's advocate a bit..

_pmf_ 10y ago

> This article should be called 'Mastering large-scale team programming'. To be fair, that IS the hard kind of programming. Small, focused teams of talented developers can do things pretty much as they like and are likely to have a positive outcome. (That's why I'm skeptical of typical "agile team" success stories; if you care enough about your job to identify with the methodology, you are probably a competent developer that would get results with mostly any methodology ... it's a self-fulfilling prophecy.)

Teeboo 10y ago
You are correct, it's just that we wrote down those behaviours and practices used by successful teams and they became the agile values. It's not self-fulfilling. It's fulfilling. The same way Doctors wrote down the treatments that worked for patients and it became medicine. https://www.youtube.com/watch?v=DHVVKAKWXcg https://www.youtube.com/watch?v=DHVVKAKWXcg

blub 10y ago

I have no idea what it should be called, but it is too abstract and short to get any use out of it. I'm not so sure about splitting developers into those types either. Sure, there are different personalities and specialisations out there, but... MVP programmer doesn't sound like one. It's too focused. But I fully agree that "Facebook" doesn't automatically mean success and good practices, just like "well known person" doesn't automatically mean being right.