It'd be interesting to compare this to "Ask HN: Habits of the master programmer?"
Mastering Programming: An Outline
81–90 of 136 posts
Re: Mastering Programming: An Outline
#82Earlier quoted context omitted.
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.
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 desc…
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.
Re: Mastering Programming: An Outline
#83Despite hating anything XP, I can strongly relate to this one:
> When faced with a hard change, first make it easy (warning, this may be hard), then make the easy change.
It aligns well with my natural process: for any problem, spend most time designing and implementing a DSL for it, and then solve it trivially in this DSL.
Re: Mastering Programming: An Outline
#84What? Seriously, what? What argument are you making here? Boxing / Ali was an analogy to demonstrate the widespread respect of the engineering community that KB has earned. /awkward To be clear; my post was not about you being boxer. /awkwardoff
You can't blindly accept everything an article says just because it is written by a respected person. It means nothing at all.
Karl Marx was also highly respected until he was proven wrong...
Re: Mastering Programming: An Outline
#85Re: Mastering Programming: An Outline
#86I updated the description of 80/15/5, a career risk management strategy.
About this item, I got me wondering: Should we never delegate a difficult work for someone that is specialist if it give us pleasure? Always we need to learn it first?
I don't agree with this, maybe I need profit instead of fun. I can found fun in a lot of other things that I can't delegate on moment.
Sorry if I am misunderstanding this part.
Re: Mastering Programming: An Outline
#87What? Seriously, what? What argument are you making here? Boxing / Ali was an analogy to demonstrate the widespread respect of the engineering community that KB has earned. /awkward To be clear; my post was not about you being boxer. /awkwardoff
You can't blindly accept everything an article says just because it is written by a respected person. It means nothing at all. Karl Marx was also highly respected until he was proven wrong...
I am not blindly following it. I think it is sound practical advice given by a titan of engineering.
I have yet to read anything of yours which says why I shouldn't listen to Kent Beck.
For every well respected opinion or technology there is always a group of naysayers. A cadre of individuals who offer nothing of insight in return.
In 1906 John Philip Sousa claimed the phonograph would ruin music. Don't be that guy.
Don't be the guy that says GUI's will never take off, that touchscreen phones will not sell, that the Godfather was a bad movie etc.
You are being contrarian for the sake of it. Kent Beck has a massive canon of work which advances the predictability and success rate of software development. You can challenge bits of it, improve it and contribute.
You are being that guy that makes sweeping generalisations which advance nothing.
What, specifically, do you think needs improved in the OP's article?
Re: Mastering Programming: An Outline
#88This 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 tea…
> 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.)
Re: Mastering Programming: An Outline
#89This 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 tea…
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.
Re: Mastering Programming: An Outline
#90Earlier quoted context omitted.
You can't blindly accept everything an article says just because it is written by a respected person. It means nothing at all. Karl Marx was also highly respected until he was proven wrong...
I am not blindly following it. I think it is sound practical advice given by a titan of engineering. I have yet to read anything of yours which says why I shouldn't listen to Kent Beck. For every well respected opinion or technology there is always a group of naysayers. A cadre of individuals who offer nothing of insight in return. In 1906 John Philip Sousa claimed the phonograph would ruin music. Don't be that guy.…
By a titan of software development processes, if there even is such a thing.
Titans of engineering are people like Torvalds, Carmack, Engelbart, Wozniak, Codd, Lamport, Wall and many many others.
Including process people in that list would be mistaken.