Not really, since the dependencies between them are now explicit. Yes the stitching is its own complexity, but divide-and-conquer is a pretty time-honored approach to effective problem solving.
> but divide-and-conquer is a pretty time-honored approach to effective problem solving.
only if you can also divide and conquer the amount of persons that will dev, because now when there was one name to learn and assign meaning to, there are ten different names.
I am speaking as someone who used to have a hard limit on function length (20 lines, in Allman style :-) ) - this ended up being really harmful and creating way too complex code sometimes.
Of course it was harmful, you were focusing on the wrong thing. The point of having methods with no more than [insert number] lines isn't because having a method with more than [insert number] lines is inherently bad. It's because long methods are usually an indication that the method is breaking the single responsibility principle. I get the impression that a bunch of programmers read Robert Martin's work, put no thought into what he was saying about short methods, concluded that the line count was the problem, and began proliferating that idea.
To give you an example, when using Java's stream functionality, I tend to insert every method call in the chain after stream() in a new line, for readability:
When I scan the method to see if it should be broken down, the fact that this code occupies 4 lines doesn't really contribute much to my decision to refactor the method into several methods, because those 4 lines are accomplishing one thing.
Plus I think there's a big difference in respect a full-stack team / tech leader garners over someone who doesn't really understand the technical challenges of half the team.
> , the main issue is just making sure to live in the actual city rather than the suburbs, if you want a city lifestyle.
Yeah but then your cost of living shoots up. I mean, I've priced Austin real estate. If I want to buy 2BR apartment in downtown Austin (the closest analogy to where I currently live in Brooklyn) I'm looking at half-million dollar properties. Which is fine for an NYC boy like me, it's what I'm used to, but then why am I moving again?
Good list, but as a contractor in the US, the one thing that sticks out that I don't agree with (necessarily) is:
-Getting 450 a day is always better than siting idle waiting for that 550-600 a day contract.
I'm fine with making a tradeoff like that for very short term work, but I don't want to commit myself to long- or medium-term work at any sort of significant discount.
If I'm confident I can get that 550 eventually, it easily pays for those days I spend on the beach.
yes, do not take a 1-2 year contract on a low rate. But mathematically:
Lets say:
Desired rate: 150
Available rate: 100
Sit idle for desired rate: 30 days
(20 working days in a month)
let's say a contract is 2 months long.
with 100 day rate yo get: 100 x 40 = 4000
with 150 day rate you get: 150 x 20 = 3000 (well if you get 200 a day, you still make the same amount of money as you would working on 100 for 2 months instead of 1)
Unless you get a significantly long contract on your desired rate. And also, that long contract gets till the end. Most likely it will, but life is bitch. You never know what would happen, it is about risk assessment.
I don't get your math entirely...if a contract is two months long, wouldn't it be 150x40 or 6000? Sure, I had to tighten my belt during month one, but at the end of month 3 I've got 6k and the person who took the 100 day rate has 4k + whatever they can make in a third month. If they extend another month at the same rate, we both have 6k at the end of month 3, except I only did 2/3 the work.
Yeah, when I worked for 5 years as a developer in municipal government, I may have had less total take home pay than some of my peers, but my "hourly rate" was easily comparable. I had 5 weeks of vacation a year to start, and worked 35 hours a week, every week.
> Everything I've seen seems so "In my experience..." as opposed to a formal proof.
The scientific method is ill-equipped to formally prove a generalized theory of software development. There are too many significant variables at play; too many equations to solve. We are left with little but "In my experience..." to guide us (as well as local experimentation, where science can actually be of some help).
I would say that you're beginning to program when you write something that iterates or recurses. With a clear terminating condition: not merely spreadsheet formulas that contain a cyclic reference whereby you iterate until some numbers appear to stabilize.
In my mind, the recognition of repeated structures in a spreadsheet count as beginning of programming. This sort of thing: "if I create this pattern of cell references and then repeat it across the grid arbitrarily far, such and such a result/behavior will emerge". It is like recursion unfolded, and on the verge of being codified compactly.
And back in the day in the UK our CSE class at 13/14 had no difficulty learning programming and that was an assembly language with only Add sub and some jump instructions
For context the UK used to have CSE and O Level Exams at 16 the CSE ones where for the vocational track kids who would leave school at 16.