[HN Gopher] Speed Matters
___________________________________________________________________
Speed Matters
Author : U1F984
Score : 157 points
Date : 2021-10-15 16:01 UTC (6 hours ago)
(HTM) web link (scattered-thoughts.net)
(TXT) w3m dump (scattered-thoughts.net)
| quickthrower2 wrote:
| I asked myself how can I code faster just now and I asked myself
| what slows me down. At the moment it's local build times. I often
| drop into Linqpad to sanity test code as sometimes even running a
| unit test is painful (because of building the code not the test
| itself)
|
| The team is longer term looking at splitting up libraries but
| maybe I should see what quick wins .Net has to offer.
|
| For side projects it's normally the startup stuff, so using those
| starter kits eg saas with login set up etc. makes sense. I'd
| definitely look at all the code so I understand it but it saves
| all that wheel reinventing and discovering the same issues
| everyone has.
| PaulDavisThe1st wrote:
| > If I was 10x faster yet it would have been 10 hours. That's a
| long plane ride. Even with a full-time job I would still be able
| to squeeze in a couple of text editor sized projects every month.
| I would be able to learn so many new things.
|
| I see a dilemma here. Nobody, not even 10x faster than the
| author, writes a full-fledged text editor in 10 hours. You can
| create something interesting that does text editing in 10 hours
| (or 100), but it's mostly going to be a learning exercise. You
| won't have created a piece of software that is of any value to
| anyone but yourself.
|
| So the dilemma involves the tension between rapidly speeding
| through many interesting "efforts" that result in nothing of any
| use to anyone, but lots of learning value to the programmer; or
| spending much, much more time creating software that is genuinely
| useful to people who are not programmers, but risking getting
| stuck in a given language, problem domain or project and not
| learning as much.
|
| I made my bed - I opted for 21+ years focused on a single
| project, but I was lucky in that it spanned everything from
| kernel-side stuff to hard-realtime to UX and I felt I'm still
| learning new stuff even today.
| Kinrany wrote:
| > I see a dilemma here. Nobody, not even 10x faster than the
| author, writes a full-fledged text editor in 10 hours. You can
| create something interesting that does text editing in 10 hours
| (or 100), but it's mostly going to be a learning exercise. You
| won't have created a piece of software that is of any value to
| anyone but yourself.
|
| You could if you had enough components to assemble the text
| editor from.
| PaulDavisThe1st wrote:
| I could stick a GtkTextView into a GtkWindow and run it
| inside GtkApplication, sure.
|
| That's not what I mean, and I don't think it's what the
| author of TFA means, by "write a text editor".
| klyrs wrote:
| The 1000000x solution: <textarea></textarea> (this is me
| agreeing with you)
| sumtechguy wrote:
| hmm I prob could make something kind of like a text editor in
| win32 fairly quickly as I can think of about a dozen built in
| calls that would make it work. Would it be full featured? Not
| much but it would do the very basics
| (cut/paste/save/read/edit). But that is because I know the
| system pretty well. If you dropped me into some other system
| it would take me a decent amount of time.
| PaulDavisThe1st wrote:
| What you're describing is precisely what I mean: "something
| that would do the very basics".
|
| Sure, I could cook one of those up, probably in less than
| 10 hours. But that's all it would do, and all I'd have done
| is learnt a few things. If I stopped right there, that's
| the only outcome: me learning some stuff.
|
| Presumably at some point, the learning needs to be applied
| to something that is actually useful?
| sumtechguy wrote:
| Almost all projects start that way as some small learning
| project. You usually do not build complete applications
| in 1 day. You usually lean heavy on existing libs or
| chunks of code you already learned somewhere else. That
| is what that sort of thing is for. In my 26 years doing
| this most of what I have written has been thrown away.
| There may still be some bits here and there living on but
| I doubt it. Yet at one point all of that code had a use
| and did it well. That use was me using that knowledge to
| get things done. Those prototype projects do a lot of
| that sort of thing. If I wanted to make an scala version
| of my 'basic editor' it would probably take me at least a
| week of digging through docs and trying things. But in
| another realm I can bash it out in a couple of hours. My
| point was your domain knowledge is what makes you a
| better developer.
| DeathArrow wrote:
| The author mistakes coding for typing. You maybe get faster at
| typing, but coding also involves thinking and doing research.
| Unless you do very repetitive tasks and you can type from memory.
| ModernMech wrote:
| I don't think the author is making that mistake. He worked on
| the Eve language, whose entire ethos was that the notion behind
| Fred Brooks' "No Silver Bullet" -- that there is no "one"
| change to development tolling/methodology that could produce a
| 10x speedup in productivity -- isn't really true anymore. In
| "Out of the Tar Pit", Mosely and Marks argue that today there
| is so much incidental complexity (from poorly designed or ill-
| fitting tools) slowing down our work, that removing it would
| result in those 10x gains Brooks argues can't be achieved in
| NSB.
|
| The question then is how do we remove that incidental
| complexity? Eve tried to do this through programming language
| design, combining Prolog-like semantics with a relational
| database and modern web technologies. In some scenarios it
| really is at least 10x more productive than other languages,
| letting you do very sophisticated things in a few hours or days
| that could take experienced developers a literal week or more
| in other languages.
|
| The author is musing here about how much he could get done as
| long as his tools get out of the way. i.e. how much more
| productive could he be if he only had to deal with the
| necessary complexity of the problem, rather than being mired in
| all the incidental complexity of the tooling. What if a
| programmer could express themselves as freely as a writer can?
| Where typing and imagination _are_ the only barriers between
| your mind and expression. It 's a nice fantasy future.
|
| Yes there is a lot of thinking and doing research in
| programming, any experienced programmer knows this. I think if
| you look at this developer's history you would agree he is an
| experienced developer who knows these things to be true.
|
| https://en.wikipedia.org/wiki/No_Silver_Bullet
|
| http://curtclifton.net/papers/MoseleyMarks06a.pdf
|
| (edit: also, I think the author addresses your criticism
| directly here: "When I think about speed I think about the
| whole process - researching, planning, designing, arguing,
| coding, testing, debugging, documenting etc. Often when I try
| to convince someone to get faster at one of those steps,
| they'll argue that the others are more important so it's not
| worthwhile trying to be faster. Eg choosing the right idea is
| more important than coding the wrong idea really quickly. But
| that's totally conditional on the speed of everything else!")
| es7 wrote:
| There are no silver bullets if you are already near the top
| of your game. However, in my experience, most engineers and
| programmers are far from working optimally.
|
| Here's the silver bullet that seems to work very well.
|
| > Master your current stack.
|
| Time and time again I see programmers who know computer
| science but really don't know their language. They run to
| stack overflow for everything from sorting to reading files.
| They make obvious syntax errors. They pause constantly not to
| think about problems, but to remember how to implement
| something simple.
|
| Most programmers can 10x themselves just by learning their
| language and stack really well.
| Jtsummers wrote:
| > In "Out of the Tar Pit", Mosely and Marks argue that today
| there is so much incidental complexity (from poorly designed
| or ill-fitting tools) slowing down our work, that removing it
| would result in those 10x gains Brooks argues can't be
| achieved in NSB.
|
| Just to clarify for others, Brooks' paper does _not_ say that
| there will not or cannot be 10x (order of magnitude)
| improvements in programming.
|
| He made two principle statements in his paper:
|
| 1. That there will not be a 2x improvement in programming
| every 2 years (comparable to Moore's Law about the increasing
| density in transistors that was roughly every 18-24 months).
| That isn't to say that there won't be 2x improvements in
| _some_ 2 year periods, but there will not be _consistent_ 2x
| improvements every 2 years.
|
| 2. That within a decade of 1987 (that is, a period ending in
| 1997) there would not be a 10x (order of magnitude)
| improvement in programming (reliability, productivity, etc.)
| from any single thing.
|
| So trying to refute Brooks' 2nd assertion, what lots of
| people try to do, by looking at changes post 1997 is an
| absurdity as it ignores what he actually said and the context
| of it.
| ModernMech wrote:
| I feel that Brooks puts a time horizon of 10 years on his
| predictions because of AI. If we achieve AGI, then that
| would be an obvious example of something overnight which
| would yield (at least) a 10x improvement of productivity.
| But I think it was a safe bet for Brooks to say we wouldn't
| be there by 1997.
|
| That said, on the topic of environments and tools Brooks
| writes, "Surely this work is worthwhile, and surely it will
| bear some fruit in both productivity and reliability. But
| by its very nature, the return from now on must be
| marginal." This claim is not timeboxed to a decade, but is
| instead projected to perpetuity. He boldly asserts without
| support that that from now on, improvements to tooling
| environments _definitionally_ cannot yield 10x improvements
| in programming. I think this is where people have taken
| issue, and have shown this claim to be wrong.
|
| I think this error comes from a misconception in the
| previous paragraph: "Language-specific smart editors are
| developments not yet widely used in practice, but the most
| they promise is freedom from syntactic errors and simple
| semantic errors."
|
| There is no reason to believe that language-specific smart
| editors could only save you from simple semantic errors and
| syntax. In fact, language specific editors in the ethos of
| Eve and Light Table supported sophisticated debugging and
| development modalities:
|
| - time-travel debugging capabilities that rewind the state
| of a program to a previous point in its execution history
|
| - what-if scenarios to test how the program would respond
| to different inputs without restarting it
|
| - provenance tracing of program state to see how it was
| calculated
|
| - live debugging and modification of a program while it's
| running
|
| - saving, sharing, and replaying program state to trace
| bugs
|
| - the ability to ask new questions about program output
| _e.g._ "Why is nothing drawing in this area of the screen?"
|
| These are not "simple semantic errors" but deep program
| analyses and insights that are not even supported by most
| (any?) mainstream languages (nor could they be without
| changing core language semantics or adding on new language
| features with orthogonal semantics). Brooks doesn't imagine
| any of this and dismisses it all as "marginal" whereas in
| my experience actually using these tools, I found them
| literally transformative to my productivity and workflow.
| TrackerFF wrote:
| By being an exceptionally fast worker, you're usually rewarded
| with more work.
| r00fus wrote:
| By finishing your assigned work exceptionally fast, you can
| focus actual effort on the "sharpening the saw" aspects of your
| role and/or the organization, and helping others.
|
| Those are the workers who (in a competent organization) are
| promoted.
| einpoklum wrote:
| > By finishing your assigned work exceptionally fast, you can
| focus actual effort on the "sharpening the saw" aspects of
| your role and/or the organization, and helping others.
|
| If you're lucky. Mostly it's when there's relaxed oversight
| over your work, so you can hide the fact that you technically
| finished your work already and are languishing doing what, to
| many people, seems like a waste of your time even if you know
| that's not true.
| TrackerFF wrote:
| If your end goal is to get promoted, there are far easier and
| less demanding ways to get there.
|
| (Not saying that you are wrong - not at all, you're actually
| quite correct that many of the people that get promoted are
| over normal performers, usually combined with some other
| talent or skill.)
| cercatrova wrote:
| Genuinely asking, is there any value anymore in promotions
| when the market seems to reward job hopping every few years?
| I think promotions were useful when someone worked only one
| or a few jobs in their lifetime, but it's not so useful
| anymore. The amount of effort to get promoted is much higher
| and with much lower reward than simply interviewing at a new
| place and getting that job within a couple weeks.
| the_gipsy wrote:
| Alternatively to promotions, you might get allowed to
| switch to that cooler project you have been eyeballing.
| PragmaticPulp wrote:
| > is there any value anymore in promotions when the market
| seems to reward job hopping every few years?
|
| Depends entirely on the company. Big tech companies are
| very good at promotions and retention.
|
| The rewards of job hopping also saturate quicker than
| people expect. Push it too far and it starts to become a
| negative. When an employer sees a resume that has a new job
| every 10-12 months for the past 6 years, they're going to
| assume the employee will be temporary at their own company,
| as well.
| dymk wrote:
| Big tech companies are bad at retention past 4 years.
| Your initial equity grant will be the largest, and once
| it fully vests, you'll see a dramatic drop in comp.
| tayo42 wrote:
| Is this true lately? Personally I got good sized refreshe
| plus more from being promoted.
| r00fus wrote:
| It is if you're actually looking to get promoted to
| management (for what it's worth). Promotion may also mean
| getting higher-profile projects.
|
| I don't know about you but the job-seeking process seems
| like another job itself. If you're good at that job (esp.
| while executing on your current job) then I guess the
| world's your oyster.
| massysett wrote:
| Exactly. As a supervisor, of course I give more work to my
| staff who work faster. This means they get more opportunities
| to learn, more exposure to good projects, more development,
| and more opportunities for promotion (if they want that.)
| spaetzleesser wrote:
| Only if you have good projects , development and promotion
| opportunities to give to them . Often it's just more work
| of the same kind.
| ajuc wrote:
| The trick is to finish slightly ahead of schedule and spend the
| free time learning, refactoring, exploring new ideas, testing
| tools, automating stuff, etc.
| Koshkin wrote:
| I would prefer if most (if not all) of those things were part
| of the normal work schedule.
| pm90 wrote:
| Whenever I've seen teams formalize this, it's been cut down
| by someone higher up who wants to show how they're saving
| costs or making the team more efficient. It's possible I've
| only worked at bad organizations, but I'm willing to bet
| that s the reason why such "benefits" are not formalized.
|
| However it then leaves you vulnerable to the naive worker
| who will voluntarily push all gears because they're such a
| hard worker.
| the-dude wrote:
| If you are a factory worker, you will be 'corrected' by your
| coworkers in the first break that comes up.
| yldedly wrote:
| The author makes a point of noting that many small improvements
| work together to make a larger speed increase, but are there
| 80/20 interventions here? What is the most effective way to
| become a faster coder?
| [deleted]
| irskep wrote:
| I've been keeping a private notes file about this. People tell
| me I'm fast, and I agree with them, so I'm trying to track why.
|
| Some examples:
|
| - Be a fast typist. At 120WPM, typing is not a limiting factor.
| I know professional programmers who do 40WPM and it limits them
| a _lot._
|
| - Have self-awareness about what is taking you time. Ask
| whether you can stop doing that. A good example of this is
| having good autocomplete: if you're looking at docs when you
| could configure VSCode (or whatever) to have the answer a tab
| keypress away, you're losing minutes per hour.
|
| - Get really good at using the fuzzy finder. Stop clicking on
| files.
|
| - Write scripts for common actions, either in `~/bin` or in
| your source directory.
| yldedly wrote:
| >Have self-awareness about what is taking you time.
|
| It's simple, but so true!
| imeron wrote:
| Sometimes I think the biggest slowdown for most coders is the
| inability to make a decision and start working in a certain
| direction. Not-deciding also includes masquerading
| procrastination as researching a subject :).
| yldedly wrote:
| That definitely matches my experience. I've learned that when
| I'm paralyzed by uncertainty, I just need to pick something,
| and in the act of implementing things I automatically make
| the decisions. But that habit needs to be honed..
| YZF wrote:
| Write a lot of code. Read a lot of code. You can try
| programming competitions. Typing speed.
|
| These are things I did as a fairly junior to intermediate
| developer. (so the first 10-15 years)
|
| Later on it's about knowing what to do, the right approach can
| be infinitely faster than the wrong approach that doesn't work.
|
| EDIT: as someone else said, know your tools, whether it's your
| IDE, your editor, your debuggers, your compilers, profilers
| etc.
| dboreham wrote:
| Hmm...there are "hunt-n-peck" typing programmers??
|
| How is that possible given that to become a programmer you need
| to type all day every day for years.
| jeffffff wrote:
| hunt and peck is probably an exaggeration but typing speed is
| not the bottleneck for programming
| https://twitter.com/id_aa_carmack/status/1302651878065475584
| [deleted]
| [deleted]
| spaetzleesser wrote:
| I never learned to type properly. I don't think it hinders my
| development speed or anything. Typing is a very small part of
| the time programmers spend while working.
| abacadaba wrote:
| don't judge me
| ModernMech wrote:
| I was a hunt-n-peck programmer because I learned how to program
| as I was learning how to type.
| jiggawatts wrote:
| I see hunt and peck people in IT pretty regularly. I also see
| an _increase_ in the number that aren 't familiar with basic
| efficiency shortcuts such as ctrl-c/ctrl-v.
|
| There are people joining the workforce as "IT professionals"
| who have not used a keyboard as their primary input device for
| most of their life. Many people have now grown up with phones
| or tablets as their primary computer.
|
| It says a lot that 90% of the time I click a WikiPedia link in
| an online forum, it is the ".m." mobile version, not the
| desktop version.
|
| Over the next decade this is just going to get worse.
| karmakaze wrote:
| For self-started projects what matters far more is maintaining
| consistent motivation and progress. For sure, there will be
| places where a good choice will pay off and save lots of work or
| bugs, but how often that happens matches the level you're at. The
| post is saying this will happen more often with practice, which I
| completely agree with. The important thing is that you keep on
| making. Consistency also matters.
|
| Don't let weeks go by AFK for no reason.
| hn_throwaway_99 wrote:
| > There are ~33k characters in the rematch repo, most of which
| are tests. I type ~500 characters per minute. So if I could sit
| down and type the correct code first time, without making
| mistakes or getting distracted, it would take 66 minutes. I don't
| see any fundamental reason why I shouldn't be able to at least
| approach that bound for such simple code - maybe get within 3
| hours, say. So there is potentially room for another 10x speedup.
|
| This seemed like a very, well, _odd_ analysis to me.
|
| My typing speed is the _last_ thing that affects my overall
| productivity.
| dgb23 wrote:
| I read it as being the upper bound and not the target of
| optimization.
| morelandjs wrote:
| I think one thing that often gets lost in these types of
| discussions, is it's not just fast versus slow. It's also patient
| versus impatient. In certain situations you absolutely need to be
| methodical, because you are stacking and layering complexity in a
| manner than is impossible to fuck the impatient way of it goes
| sideways.
| ChrisMarshallNY wrote:
| I enjoyed the read.
|
| _> If you compare two coders, one who can touch type and one who
| has to hunt and peck, the difference between them is not just
| down to typing speed. The hunter-and-pecker has to think about
| typing! This consumes attention and short-term memory that is
| sorely needed for thinking about the program itself._
|
| I never learned to touch-type, but I've also typed _a lot_ of
| stuff[0]. I seem to be a lot faster than most folks, and I write
| _wordy_ code. Take a look at my codebases, to see what I mean.
| _Lots_ of documentation[1].
|
| Also, I have a friend who is an _amazing_ programmer, but has
| been absolutely clobbered by RSI. It looks like the worst case I
| 've seen. He's had at least one operation. Maybe two, by now. I
| think they didn't fix the issue, just ameliorated it a bit. It
| really does break my heart, because I consider him to be a
| treasure to programming.
|
| I like my code to be performant, and I seem to be able to get
| releases out the door in good time, but I suspect the author
| would go crazy, looking at me work.
|
| [0] https://stackoverflow.com/story/chrismarshall
|
| [1] https://littlegreenviper.com/miscellany/leaving-a-legacy/
| buescher wrote:
| My thoughts on "good, fast, cheap, pick (at most) two":
|
| 1) If you're not fast you will never get good 2) There's no such
| thing as "good, slow, and cheap" and if there is, that person is
| booked for the next 30 years
| hyperpape wrote:
| As the developer (but not the OP, of course), cheap is not an
| attribute I'm inclined to optimize for...
| buescher wrote:
| Yeah. Aspire to be good, fast, and expensive. Also, slow gets
| expensive fast anyway.
| Traster wrote:
| One of the things that my most recent job really highlighted was
| - speed matters, but you need to know _how_ it matters. In my
| particular niche essentially there were cliffs. If you were
| faster than x, you got y, if you were faster than x2 you got y2.
| Basically, you could halve the latency of your system for 0
| benefit. You could decrease the latency of your system by 5ns and
| the benefits would be amazing. You could gain 5ns and it 'd be
| nothing.
|
| Speed does matter, but first, you need to know now.
| AlexanderDhoore wrote:
| This obsession with productivity is not healthy, and a young
| man's game. Relax for a second, will ya. Think before you act.
| imachine1980_ wrote:
| Old people don't understand, we need more reasons to use
| Adderall
| [deleted]
| chriswait wrote:
| Maybe you misread the article - the obsession here is with
| "speedup", which is not the same as productivity.
|
| The author gives the example that instead of simply doing more
| X, being faster can enable you do Y instead of X (where Y might
| be only working half-days). Very much "work smart not hard",
| which is where a lot of grind-y productivity stuff lands.
| TeMPOraL wrote:
| It's not an obsession with productivity. Speed of the tools we
| use limit the thoughts we can think.
| convolvatron wrote:
| nothing is more frustrating for me that to have a goal, and a
| path, but be unable to get there because of .. issues. i know
| thats programming and working in an organization
|
| but if it is going to take me a year to deliver an X, I
| probably wouldn't choose to do it. a month, hell yes. the
| worst - pulling the trigger on X assuming it will take a
| month + delta and have it take a year.
|
| there's also the reward and momentum factor. if i keep
| getting nice wins i get pulled into doing more interesting
| work. if its going to be another 6 weeks before i can see any
| demonstrable progress... i'm actually going to go alot slower
| and be tempted to just forget the whole thing.
|
| some of us are actually in it to _do stuff_....not just show
| up at standups and collect a check. honestly though maybe i
| have less to show for wanting to dig into real work.
|
| another important context here is that Jamie is driven by a
| desire to make programming more useful and accessible to
| people. the fact that he's trying to quantify that is quite
| interesting and relevant to that goal.
|
| so .. put in your 40 hours and have a life. there are other
| people with differnt goals.
|
| edit- sorry temporal, it doesn't sound like it , but i'm
| really agreeing with you
| bob1029 wrote:
| You can still be hyper-productive without killing yourself in
| the process. Also, some people actually like to do these
| things.
|
| Keep in mind that there is a point where relaxation turns you
| into a worthless bum, and constantly analyzing things before
| you act will mean you struggle to learn which paths don't work
| in reality.
| mental1896 wrote:
| It's possible to walk a line that straddles both approaches.
| snek_case wrote:
| I agree and I would say that choosing to work on the right
| things is much more important than being a fast programmer.
| Sometimes you need to spend more time thinking about a problem,
| do a bit of a "market study", or gather more data. Too many
| startups out there are solutions looking for a problem. On a
| smaller scale, as an individual programmer, it's easy to get
| caught into yak shaving or trying to optimize the wrong thing.
| Jensson wrote:
| > choosing to work on the right things is much more important
| than being a fast programmer
|
| Choosing to work on the right things is completely orthogonal
| to being fast though.
|
| > Sometimes you need to spend more time thinking about a
| problem, do a bit of a "market study", or gather more data.
|
| You can do this even if you are a fast coder. Only difference
| is how long it takes to test things, build MVP's and show
| them to potential users. MVP's are a great way to better
| understand what to build or do market studies, so I don't see
| why this goes against being fast.
| danielovichdk wrote:
| Speed doesn't matter if you're doing the right thing.
|
| Writing code can't be done quick without knowing what you need
| the outcome to be.
|
| Then speed is set by how fast you type.
|
| But it's a theory, and practice no one writes code without having
| to put thinking into it.
|
| So speed is not a measurement I would ever count as a good trait
| in terms of quality. And quality cannot be measured, so we're
| back to why speed is even interesting in productivity of software
| creation
| ModernMech wrote:
| > Then speed is set by how fast you type.
|
| Ideally, but that's not always the case. For example, let's say
| my goal is to write the program that outputs Hello World. In
| some languages it's as fast as writing the literal characters.
| The only extra burden is maybe to put quotation marks around
| them. "Hello World"
|
| 13 characters total. But if I did this in Java for instance,
| well that's a different story. Now the program looks like this:
| class HelloWorld { public static void main(String[]
| args) { System.out.println("Hello World");
| } }
|
| 87 characters total. The original program could have been
| written 6 times over in the time it took to write just this
| one. But that's not the real issue. The real issue is that not
| only do I have all that extra syntax, I have a whole bunch of
| new concepts to contend with including classes, scopes,
| functions, function composition, console arguments, lifetimes,
| access, types, arrays, objects, and methods. I can't just do a
| thing, I have to do all this extra work before I can do the
| thing. In the first case I have a single concept in my mind:
| String. In the second case I have to keep not only N concepts
| straight, but how they compose as well, and all the arcane
| rules therein.
| jiggawatts wrote:
| This is like those reviews of operating systems that are 50%
| about the installation process, even though most people
| install their own operating system _at most once_ , and most
| likely _zero times_. Then go on to use it for years and
| years. Making the "issues" listed in the review something
| that affects 0.01% of the time interacting with the product
| being reviewed.
|
| Most developers are working on a codebase where they did not
| personally write that "void main(...)" boilerplate! Someone
| else did all the initial scaffolding, they joined the team
| years later, and they're adding new feature "X".
|
| In terms of productivity, all of those things you listed as
| negatives due to the mental load they impose are absolutely
| essential for this scenario of a team member joining and
| having to modify a large code base. Scopes, lifetimes,
| classes, interfaces, etc... are the levers for the mind that
| enable teams to work together successfully.
| mike_hock wrote:
| I'm not really sure what the parent poster was trying to
| say. It seems like an abstract example, but then goes into
| way too much detail about the actual language concepts Java
| brings to the table.
|
| Obviously one can't take the time from zero to Hello World
| as a benchmark for productivity.
| lordofmoria wrote:
| > An example of one of these, the most commonly cited bad-thing-
| to-optmize example that I've seen, is typing speed (when
| discussing this, people usually say that typing speed doesn't
| matter because more time is spent thinking than typing). But,
| when I look at where my time goes, a lot of it is spent typing.
|
| I'm glad someone agrees with me on this. The argument that "I
| don't spend a lot of time typing" is just false. Furthermore, if
| you're good at typing, you free up brain cycles to allocate to
| higher level work. Slow typers severely underestimate how much
| brain power is spent on that.
| renewiltord wrote:
| On my Macbook Pro, I have Caps Lock mapped to Esc. But every
| time I hit Caps Lock there would be a pause before the Esc
| triggered. Since I use vim bindings everywhere this was a
| nightmare as I switched to normal mode. I was like way less
| productive. It was nutty.
|
| Fixed it using Karabiner as recommended
| https://superuser.com/questions/317900/eliminate-macbook-cap...
| and suddenly I was better at life.
| localhost wrote:
| Another option is to map Caps Lock to CTRL and use the
| default vi CTRL+[ keybinding for ESC. You get the bonus of
| being able to use a more ergonomic CTRL for virtually
| anything else that requires CTRL.
| fabianhjr wrote:
| I learned Dvorak for the speed and remained due to a perceived
| lower strain on my hands.
|
| (Another bonus is that now I cannot hunt and peck since my
| keyboard still has the qwerty imprints and I guess that is the
| biggest contributor to typing speed from learning Dvorak)
| dharmaturtle wrote:
| I can't touch type symbols. (!@#$%^&*)
|
| I can feel my brain stutter every time I need to type an
| esoteric operator.
|
| ...okay I know what I'm doing this weekend.
| copperx wrote:
| It's not that hard as learning to touch type the entire
| alphabet! And I don't consider those symbols esoteric, unless
| you're programming Lisp.
| dan-robertson wrote:
| Mostly you would only use (*) from that list for lisp. Some
| lisp hackers are known to remap the first row of their
| keyboard to be shifted so that one needn't hold shift to
| type parens.
| the_gipsy wrote:
| > Furthermore, if you're good at typing, you free up brain
| cycles to allocate to higher level work.
|
| Yes exactly! I finally learned to touch type including symbols
| on ortholinear keyboards. This frustration of having to look
| down constantly is gone. I'm free to focus on editing code.
| titzer wrote:
| Missed in this analysis is just how much time it takes to
| _debug_. I have found over the years that I spend at least an
| order of magnitude more time debugging something than writing it.
| And that gets worse if the debugging is separated from the
| writing by days, weeks, or months, because of the context reload
| and the general head-scratching trying to figure how it is
| supposed to work and what I did wrong.
|
| I found over the years to avoid long debugging sessions, I can
| instead write better tests, do smaller commits, and write less
| clever code. To prevent the kinds of bugs that crop up months
| later, it's really important to write really good, comprehensive
| tests.
|
| A lot of tests that are too coupled with the design are also bad,
| though. They slow refactoring. So you have to get good at writing
| the kinds of tests that don't inhibit refactorings, or get good
| at designing things so you don't have to refactor.
|
| Coding speed is irrelevant in the long run. It's only relevant
| for quick scripts and throwaway code.
|
| Don't get sucked into debugging.
| Jensson wrote:
| To me coding speed is the speed at which you write code with
| few enough bugs that it is fine to run it in production. So
| debugging is included in that number, if you have to spend so
| much time debugging your code then you aren't a fast coder.
|
| If you write a ton of bad code yesterday and got nothing done
| today since you had to debug all day, then you weren't fast
| yesterday and slow today, you were slow both days.
| gnulinux wrote:
| You can still write code, test it, debug it, release to
| production; then weeks or months later someone finds a bug in
| it (in prod). GP's point is that this kind of debugging sucks
| a lot more time than writing feature's v1 code from scratch.
| And I agree.
| Jensson wrote:
| But that bug is also chalked up to your original time. The
| time it takes to make feature X is the implementation time
| + all maintenance time. If that combination isn't low then
| you are slow.
|
| For example, lets say you spend a full year writing a full
| product. The a bug you write at month 2 and fix at month 6
| is still the time it took to build this product. Being a
| quick coder therefore includes being good at managing
| technical debt, bugs etc. There is no reasonable
| interpretation of being fast at it that doesn't include
| these aspects, as the clock doesn't stop ticking until you
| are done.
|
| So when people say you should learn how to become a fast
| coder, what they mean is that you should learn how to
| produce code at your current quality level but in much less
| time. They don't mean that you should throw quality out the
| window and just write crap without thinking.
| UnpossibleJim wrote:
| |I found over the years to avoid long debugging sessions, I can
| instead write better tests, do smaller commits, and write less
| clever code|
|
| The less clever code part is the key, for me. If I can write my
| code out, in a relatively simplistic way and go back to
| refactor and optimize it, I save myself hours of debugging
| headaches.
|
| Doing it and saying it are different things, but I fully intend
| to do it every time I start =)
| hinkley wrote:
| Doing something a second time is almost always faster.
|
| You can't draw any information from this, except perhaps that the
| author avoided Second System Syndrome.
|
| In college I worked with students who had programming jobs. While
| my classmates were spending fifteen+ hours on assignments, one of
| these coworkers who I shared a class with said he was spending
| two hours and I thought he was lying. Another was claiming three
| or four. This must be bravado I thought.
|
| Next summer I got a programming job too. That fall I was spending
| six hours on homework, and by year's end I was down to three.
|
| When everything is new you go slow. You have to solve problems
| without muscle memory, and you have to fight nervousness. Am I
| doing this wrong? Is this even a good answer?
|
| They talk about 10000 hours and mastery, but there are also clear
| breakpoints at 100 and 1000 hours, where you know enough to do a
| lot, and you don't have to stop to consider your first moves.
| josephg wrote:
| There's a few other variants of this:
|
| When I was a TA marking assignments I saw a huge range in the
| number of lines of code between my students' assignments. If I
| took all the students who got full marks, there was often a 2x
| or 3x size difference between the smallest submission and the
| largest. And the large assignments didn't look bloated. If you
| gave me the code from a random student, it wasn't obvious where
| in the size range their code would land.
|
| And a couple years ago I worked as a professional programming
| interviewer. One of the assessments we did was a half hour
| programming problem. I interviewed over 400 interviews. Most of
| them had some professional experience as software engineers.
| Candidates use their favorite language and their own computer &
| tools. Quantitatively, there is a _massive_ difference between
| the better candidates and the worst. The strongest candidates
| could get about 2-3x as much done in the same amount of time as
| the average. And the weaker candidates (even those with
| professional experience) could barely implement hello world
| within half an hour.
|
| As software engineers, we don't have a culture of practice. Its
| assumed that with enough time working professionally, we'll
| keep improving. But that might be naive. There are almost
| certainly ways to measure our skill and improve over time. Its
| weird we don't even have that conversation.
| ZephyrBlu wrote:
| > _As software engineers, we don 't have a culture of
| practice. Its assumed that with enough time working
| professionally, we'll keep improving_
|
| Man, this is exactly what I've been thinking lately.
|
| I don't have that much professional experience and have a
| background of competitive gaming where there is a really
| strong culture of explicit practice.
|
| Coming to software development where people with a lot of
| experience can't articulate their process or the steps they
| took to improve is really fucking annoying.
|
| I don't expect a step-by-step manual, but I do expect
| _something_ instead of it all being tribal /intuitive
| knowledge.
| legulere wrote:
| Also between the first and the second time you have plenty of
| opportunity to plan ahead for what you are going to do
| differently next time.
| hinkley wrote:
| Yes, but that's the trap of Second System. You can have _too
| much_ time to plan and you end up with a baroque nightmare
| that everyone resents, including (eventually) you.
| MarkLowenstein wrote:
| When something becomes routine for a developer, where they can
| predictably finish a work item without designing anything new,
| that task is immediately flagged in managers' minds as one that
| should be done by a more-junior/contractor/3rd-party/off-the-
| shelf solution. Almost by definition, then, good developers are
| relegated to _only_ doing tasks that they are doing for the
| first time. The implications of this natural law are evident in
| the quality of the output, the predictability of the schedule,
| and career burn-out of people who are asked to be creative 100%
| of the time.
| karmakaze wrote:
| I wish this was true. I'm always finding myself moving around
| in an organization and projects trying to find new challenges
| rather than building another standard API. Certainly every
| project has it's critical pieces where any extra attention
| can pay off but not so many.
| MarkLowenstein wrote:
| What type of company do you work for? It may be different
| in software/services vs. commerce companies.
| xmprt wrote:
| I think doing things for the first time is still something
| you can get better at. Although you're working on brand new
| problems all the time, you can still improve at skills like
| digesting the problem, splitting it into subproblems,
| designing systems, faster implementations and testing.
| hinkley wrote:
| I still spend a lot of my time manipulating lists. Although
| it may be fair to say that experience helps you realize that
| you _can_ turn some problems into manipulating lists. Easier
| to write tests for, and for the next person to understand.
|
| The problem, from the manager's standpoint, is that the
| really good solutions are simpler than the really bad
| solutions. That may not sound like a problem, but the
| concise, correct answer is often self-evident in retrospect,
| diminishing the gravity of the situation.
|
| Lots of people make suggestions you instantly agree with, but
| you would not have come up with all of those suggestions on
| your own. A bad boss won't understand that, until you make
| another self-evident decision that you would get more money
| and respect working somewhere else. Maybe not even then.
| jimbokun wrote:
| My son was taking his first programming course, and was
| watching him working on an assignment. He was running the
| compiler and executing his program in the terminal.
|
| I mentioned to him: "Did you know you can pull up your past
| commands by hitting up arrow?"
|
| His mind was blown. I think that comment doubled his
| productivity.
| zxexz wrote:
| For bash users who are used to vi-style keybindings, you can
| enable vi mode[0]. When I discovered this, my "performance"
| must've more than doubled :)
|
| [0] https://blog.sanctum.geek.nz/vi-mode-in-bash/
| brightlancer wrote:
| My command line time is easily halved by using vi mode in
| Bash.
|
| (And so many coding tools are inefficient to me because I
| cannot use vi keybindings.)
| tomjakubowski wrote:
| Next lesson: bang commands!!
| https://www.redhat.com/sysadmin/bash-bang-commands
| mym1990 wrote:
| I am working with a junior developer who will use the mouse
| to click on text, click copy, click the new area, and click
| paste. I don't have the courage to tell him that he can
| Control/Cmd-C and Control/Cmd-V
| drran wrote:
| In Linux, just select and middle-click.
| dkarl wrote:
| This blew my mind when I first saw somebody do it. I was
| a bright-eyed young engineer in shorts visiting a
| customer site, and he had a PhD, dress slacks, a white
| button-down shirt, and a tie. I assumed had a jacket to
| match the slacks hanging in his office. I said, "Whoa,
| what terminal emulator is that? I need to check it out."
| It was xterm.
| slivanes wrote:
| Just let him know.
| gibolt wrote:
| And you may have to show him during pair programming.
| Telling someone 10 improvements rarely changes their
| workflow.
|
| Letting them see/discover the change will drive them to
| try
| Jtsummers wrote:
| And the next lesson: C-r will search the command history (at
| least in most *nix shells). So when needing to do something
| but you aren't sure how far back it was (not on the screen or
| not recallable) but you know it is in the history and some
| text in it, just C-r <something> [C-r repeatedly until you
| get to the correct version].
| mindcrime wrote:
| Related trick: type the first couple of characters of the
| command in question, and hit PGUP until you find the
| correct version.
| nitrogen wrote:
| This one's my favorite. Not every distribution of
| readline enables this, so you might need to uncomment or
| add the binding for history-search-backward/forward into
| _/ etc/inputrc_ or _~ /.inputrc_. Similarly editrc for
| programs that use libedit instead of readline to avoid
| the GPL.
| cogman10 wrote:
| Just as useful,
|
| history | grep pattern
|
| With all the useful grep abilities (like peaking at
| commands before or after the given pattern).
| d0mine wrote:
| Try fzf
| mindcrime wrote:
| I do this a lot as well. A useful side-tip to go with
| that: set your bash history size to be unlimited (or at
| least really big) to avoid losing less frequently used
| commands.
| blastro wrote:
| i only recently learned this. been big
| mrich wrote:
| On Windows, Ctrl+Backspace will delete the word left from
| the cursor, Ctrl+Delete the word to the right. It's pretty
| much unknown as far as I'm aware but it has boosted my
| editing productivity immensely.
|
| vi users will probably laugh at this.
| NortySpock wrote:
| Thank you for posting this; I had ctrl-arrow-key left or
| right to jump words but this is magical.
| djokkataja wrote:
| Actually as a Vim user I have Ctrl+Backspace mapped for
| insert mode. But I learned Windows shortcuts before
| vim...
| copperx wrote:
| Unknown? You can't work inside Windows at all without
| those shortcuts. In Emacs it's alt+Backspace, so it's not
| too hard to organically find in other environments by
| trial and error.
|
| Whenever I switch editors, I quickly look for the
| following shortcuts:
|
| * How do you delete a word forwards and backwards? (there
| might be a better shortcut such as Ctrl+W)
|
| * How do you move to the word ahead and the word behind?
|
| * How do you kill a line?
|
| * How do you duplicate a line?
|
| * How do you move a line up and down?
|
| * How do you activate multiple cursors?
|
| * How do you comment/uncomment a line/block?
|
| * How do you expand/contract a selection?
|
| I think that covers about 80% of the common actions, and
| learning them will make you instantly productive in your
| new editor.
| funkymike wrote:
| Some other very handy shortcuts in MS Office programs
| (and maybe others) is alt-shift-up/down arrow will move
| the entire line up or down. Quite handy to move text
| around when composing an email for instance.
|
| Ctrl-up/down will move the cursor past newlines, so you
| can more quickly navigate when there are long lines with
| lots of wrapped text.
| dumpsterdiver wrote:
| One of my favorites is option-arrow (left or right) to
| jump between words in the terminal.
| dan-robertson wrote:
| If it's readline-based like bash and you are still using
| default shortcuts then you can do M-b and M-f for
| backward/forward a word at a time (not sure what the Meta
| equivalent is on a Mac. On my keyboard it is the 'Alt'
| key.) Many Mac apps/text inputs support emacs-style
| shortcuts like these.
| d0gsg0w00f wrote:
| set -o vi
| bwill94 wrote:
| I got a laugh out of helping a PhD ML researcher who was
| having problems with their keyboard. They showed me how
| they had lowered the repeat delay on their wireless mac
| keyboard, and now when they typed, it went nuts and
| stayed stuck on repeat randomly. The reason they lowered
| the delay was that it was taking too long to delete the
| long command they had (they wanted to hold down delete to
| clear everything out). I was able to show them that there
| was interference from their USB-C dock which likely
| caused the key up events to be dropped - and that they
| could also use the option key to delete entire words at a
| time.
| eric_b wrote:
| To me, this is not a lesson about speed, but rather a lesson
| about "compound interest". He was able to compound all his
| learnings from the first go round in to the second. That doesn't
| always mean it will go faster, but it does usually mean you don't
| make the same mistakes as the first time (which _can_ result in
| speed).
|
| I find this notion of compounding to be much more useful in life
| than just in terms of finance and interest. Starting early, or
| doing something more, yields a compound benefit down the road.
| You get better at a thing faster, which compounds and lets you
| get better still. It's how expertise is realized and why there
| will never be equal outcomes between different people with
| different levels of motivation and persistence.
___________________________________________________________________
(page generated 2021-10-15 23:01 UTC)