121–130 of 130 posts
Thinking about this stuff is the sign of either a newbie or lacking up-front design.
Earlier quoted context omitted.
Also kind of related - programming by "wishful thinking". You first lay out the flow of the program as calls to high level functions which don't yet exist, and then go back and fill in the functions as you can. The first few SICP video lectures are all about this style, and I found the idea simple but very useful to avoid trying to hold too much of a problem in your head at once.
I've found what I think is the SICP book, but I can't track down the video lectures - can you provide some links? Thanks - I thought I was the only one programming by "wishful thinking"!
The Bad Guys want you to feel insecure about your work, your position, your relative standing, and everything else because their worst nightmare is that software engineers and scientists and thinkers wake up and realize how much leverage they would actually have if they were organized and capable of looking out for their own interests. We'd reshape the entire business landscape, and the power relationships between us…
Really? From my experience the "Bad Guys" don't give a shit about code quality and will shower you with praise if you give them the crappiest code possible, as long as you make the changes they want 5 minutes ago. This article is really talking about the insecurity that other programmers inculcate, because we're all very smart and all very competitive.
With that, I'm inclined to agree with the parent, though perhaps his use of Bad Guys does detract from the underlying message. I don't think there is some deep plot by born-evil people to keep programmers down, but I agree with the point that we could all do much better by working together in a positive way instead of trying to out-shame each other in hopes of capturing the top prize of impressing someone else.
Earlier quoted context omitted.
Sadly that does not work in enterprise multi-site projects with outsourcing across several companies.
Yup; which is why the people getting hired for those projects would flounder if asked to make a large individual contribution without much handholding; and also why those types of project team structures yield such incomprehensibly shitty software (at ridiculous cost to the client.)
I would agree about the general outcome, though - enterprise software often is built _despite_ the politics between various departments and vendors, and much of the solution is as a result of compromise and integrating with "not quite suitable for current purpose" legacy systems. That is where a large amount of the cost goes. (It's also important to remember that what we're building today is also going to become the legacy system of tomorrow, and to include that thought in the design).
Earlier quoted context omitted.
Yup; which is why the people getting hired for those projects would flounder if asked to make a large individual contribution without much handholding; and also why those types of project team structures yield such incomprehensibly shitty software (at ridiculous cost to the client.)
Seriously? Many of the enterprise devs I know do make large individual contributions in their own (side) projects, or in smaller projects within the organization. Part of enterprise dev is that you are developing within a series of constraints, not least the thought in mind that there is likely to be someone maintaining this code in 10 years time, and it's unlikely to be the team building it today. I would agree abou…
That said, don't dither too much over writing code. History favours the doers rather than the vacillators. Most software except for utilities has a quite short working life anyway. There is also the standard advice of "expect to throw one away".
Earlier quoted context omitted.
Executives don't care about that specific flamewar (or even know that it exists) but they like creating environments where we slug each other over minor, superficial differences in coding style because (a) it makes us look stupid and petty, and (b) it tires us out and makes us even easier to steal from. Programmers are often oblivious, when they find themselves in work environments that are designed to play divide-an…
Please seek out a therapist to talk to. You can't be happy with the level of anger and resentment that you seem to have right now. At first I thought you were an attention seeking jerk, but after reading your comment history, I think you have gotten yourself into a bad place in life. Please consider it.
Earlier quoted context omitted.
> Improve your code by making it do less not more. Exactly. The problem is that code can tend to be either crap (spaghetti) or too much code (too many methods and layers of extraction). So, I'd go one step further: code should do less, not more, and should be clear and understandable, without making unnecessary sacrifices. What is clear to me isn't clear to everyone else, but striving for clarity and simplicity isn't…
> too many methods and layers of extraction Surely, you mean abstraction?