[HN Gopher] What does it take to be a good programmer?
___________________________________________________________________
What does it take to be a good programmer?
Author : ingve
Score : 57 points
Date : 2022-08-28 13:09 UTC (1 days ago)
(HTM) web link (qristin.wordpress.com)
(TXT) w3m dump (qristin.wordpress.com)
| worik wrote:
| Expressing complex ideas in concise manner, as simply as
| possible.
|
| A bit ironic in this context
| latchkey wrote:
| 0. Learn how to name things.
|
| 1. Anticipate cache invalidation issues.
|
| 2. Write tests to avoid off by one errors.
|
| https://twitter.com/codinghorror/status/506010907021828096
| revskill wrote:
| I teach programming, too. My way of teaching is not much about
| computer, it's more about thinking, drawing and writing (not only
| code).
|
| - Thinking about steps, divide and conquer.
|
| - Drawing or visualizing the steps.
|
| - Writing documentation clearly before any code is written.
|
| Most of new programmers tend to think just make program work
| means DONE. No, it's not, it's just the last part of what to be
| done.
| BirAdam wrote:
| The single most useful thing I ever learned was how to break
| down a problem, make steps to a solution, make a flowchart of
| said steps, and annotate the flowchart with pseudo-code. After
| that, making the software was trivial. Even with that toolset
| I'm likely mediocre at best.
| Sohcahtoa82 wrote:
| Yeah, to me, that's all programming is. Taking a task,
| breaking it down into tiny steps, and writing those steps
| down in a language a compiler/interpreter can understand.
|
| The problem is trying to break down MASSIVE problems. Back
| when I was frequently dealing with newbie programmers, it was
| common to find ones that wanted to make an MMORPG while they
| could barely grok for-loops. They hadn't even completely
| understood what programming is, yet wanted to take on making
| a massive project that usually takes multiple teams.
| randomdata wrote:
| How would you begin to understand programming (or anything
| for that matter) without first starting with a massive
| undertaking and breaking it down into smaller chunks that
| can be discovered? Give someone a for-loop in isolation and
| it means nothing. They will never really understand it
| because it doesn't relate to anything. Given something
| massive they will have to break it down, and in that it
| will dawn on them "Huh, I need to do this same thing over
| and over again. I wonder how I might do that?" at which
| point they will discover loops, and then it will make
| perfect sense.
| onion2k wrote:
| _make a flowchart of said steps_
|
| This is how you end up with software that does the job it
| needs to do perfectly well when all of the expected inputs
| and environment are correct, but completely fails if anything
| unusual happens, because 'it wasn't in the flow chart'.
| ChrisMarshallNY wrote:
| _> You need to be really smart and have a scientific mindset.
| Most importantly you need to love learning new things._
|
| I'm not so sure that these are _required_. I think they are more
| akin to "commonly found characteristics."
|
| Especially the "scientific mindset" part. I have a _disciplined_
| mindset, but I suspect most scientists would take issue with me,
| calling it a "scientific" mindset.
|
| In my experience, being _a good problem-solver_ is more important
| than just about anything. Being able to "divide and conquer" a
| problem, sniff out root causes, and not settle for symptomatic
| fixes, etc. Stubborn might be more important than smart.
|
| We also don't all have to be Mensa members. Many programmers are
| probably not much smarter than their peers in other disciplines.
|
| But "love learning new things" is, while maybe not "required," at
| least _quite helpful_. It certainly applies to almost _any_
| vocation; not just software development.
|
| But the real gist of her essay was that it helps if programmers
| are good with _people_ , as much as with _machines_ , because
| they connect better to the end-users of their work.
|
| Whether or not being "good with people" is required is debatable,
| but I think that it is important for everyone to keep an eye on
| the final deliverable, and its operation in the context of the
| end-user.
|
| In my experience, many organizations go well out of their way, to
| ensure that engineers _never_ hear directly from the user. That
| 's Marketing's job, and Thou Shalt Have No Other God Before Me...
| etc. I've watched Marketing people throw _huge_ tantrums at
| engineers that "dare" to suggest that they might envision the
| way their work would be perceived by the end user.
| tunesmith wrote:
| I worked with someone who didn't have what I'd call a
| scientific mindset, and it can really be a limiting factor.
| They confused correlation with causation, in other words were
| quick to launch on to theoretical explanations without testing
| or proving their thinking. When solving a problem, they tried
| tons of different approaches until they empirically found one
| that worked, without always fully rationally understanding the
| cause of the symptom they were trying to remedy. They usually
| succeeded, but the cost was the time spent, and the complexity
| of code that resulted.
|
| There are a lot of ways to be a programmer, but that is not one
| of the better ways. The programmer was productive (prolific)
| enough, and the business was resource-constrained enough, that
| their work quality was not even close to consider firing or
| replacing, but I'm convinced it cost the team and the company a
| lot of productivity and effectiveness over time.
| ChrisMarshallNY wrote:
| Sounds like a bad problem-solver.
|
| Maybe a good problem-solver is "scientific." Dunno. I have
| never had "scientific" training, but I have had _plenty_ of
| "problem-solving" training.
| greenhearth wrote:
| I understand she is frustrated with the amount of new tech to
| learn, but why did she have to shit on teachers? That analogy was
| a mess of false equivalency and defective induction. Did it even
| prove any point (whatever the point was... "looking back on
| things," I suppose... oh, brother)?
| cientifico wrote:
| Can listen
|
| Can communicate
|
| Can maintain the global picture in mind
|
| Can understand that code is about communicating with other people
|
| The rest just comes...
| TrackerFF wrote:
| I have to admit, some of the absolute best programmers I've
| personally known, seemed to share these qualities:
|
| - Natural curiosity, exploring all kinds of technical /
| scientific topics - not necessarily programming alone.
|
| - Extreme eagerness to learn. I'm absolutely not the kind of guy
| that can just immerse myself in technical books, but these guys
| are the types that would dedicate their spare time to really read
| and understand relevant literature.
|
| - Intellectual acumen to easily pick up concepts. This was
| especially apparent when you studied with them - and could see
| how they compared to the rest. While others would struggle with
| some topics for weeks, even months, some of these would pick them
| up in the mater of hours. But I also think this is equally due to
| having strong background, and really knowing the fundamental
| stuff.
|
| - Strong discipline. Showed up to work / school / etc. every day,
| put in all their hours. Little slacking around.
|
| - Willingness to discuss and teach others. On the contrary to the
| "arrogant genius" stereotype, most of the really strong people I
| know have been eager to teach or show - at least as long as the
| interest has been genuine.
|
| Probably forgetting a lot of stuff - but those have been some of
| the patterns I've noticed. The really good programmers and
| engineers I know have spanned from high-school drop-outs to
| research scientists.
| benjaminjosephw wrote:
| > We need to stop admiring those smart enough to understand how
| the software works, and start making the software easier to
| understand in the first place.
|
| Yes, I agree. But I think it does take a lot of design skill to
| achieve the latter. Making the complicated simple is not an easy
| task. Hoare described a similar problem like this[0]:
|
| > There are two ways of constructing a software design: One way
| is to make it so simple that there are obviously no deficiencies,
| and the other way is to make it so complicated that there are no
| obvious deficiencies.
|
| > The first method is far more difficult. It demands the same
| skill, devotion, insight, and even inspiration as the discovery
| of the simple physical laws which underlie the complex phenomena
| of nature.
|
| [0] The Emperor's Old Clothes (1980) -
| https://web.archive.org/web/20220428130737/https://www.cs.fs...
| samhuk wrote:
| > In todays field of software development, people don't come into
| it
|
| To be as polite as possible without being dishonest; wow, there
| are a few rather sweeping, unsubstantiated, boiling hot takes
| embedded throughout there, i've just quoted one.
|
| From my experience, most of what features here just simply isn't
| true, or is _at least_ very anecdotal. Just as one example, i 've
| never worked for any software company that "wasn't about the
| users". You really do just only need to look at how much "UX
| Specialist" roles have meteorically exploded over the last
| ~decade or so, as companies compete to offer increasingly
| smoother user experiences, and it is hammered into the actual
| developers too as a core operating principle everywhere i've
| worked.
| BeetleB wrote:
| > Just as one example, i've never worked for any software
| company that "wasn't about the users".
|
| Try working for any of the major CAD companies. They are openly
| user hostile :-)
| drewcoo wrote:
| > i've never worked for any software company that "wasn't about
| the users"
|
| Startups are going to tend to have devs focused on users and
| "quality is everyone's job" etc. In fact, you should never hear
| the phrase "that's someone else's job" in a startup.
|
| Big corp jobs, especially at non-software companies will tend
| to treat people as isolated cogs in the big machine, a machine
| you're told by everyone is "someone else's job" to understand
| and steer.
|
| The article isn't dishonest. It's that the experience of "being
| a programmer" varies very widely. Our field has no professional
| standards.
| cryptozeus wrote:
| good article to read however op is missing few points imo...
|
| "I hope we'll manage to find a better balance between the
| eagerness to learn new tech, and the focus on actually delivering
| value."
|
| This is not always up to dev, org level changes to move to cloud
| or use new tech happens at mngr/arch/lead level. There needs to
| be trust in new tech as well as doubt if it solves the problem. I
| totally disagree with this thinking against new technologies. Can
| you imagine not going to cloud in 2022 and deal with old server
| technologies ?
| EddySchauHai wrote:
| I rarely use the cloud at my current role and it was pretty
| awesome to see sysadmin skills I got when I started in 2014
| were still relevant. Sometimes I wonder how insanely productive
| a PHP developer must be when he's given an Apache Server and
| MySQL to build a CRUD app after 20 years experience of a single
| stack, compared to my eight years experience of completely
| random technologies.
| 29athrowaway wrote:
| The traits that are favored in one type of programming are not
| favored in other types of programming.
|
| If you do systems programming on scientific, medical, defense
| systems you will be risk averse and conservative, and take your
| time and perhaps be successful. But those same traits will not be
| favored in let's say, web development for a seed stage startup.
|
| Understanding things from the ground up can be good for some
| occupations, in others, everything that matters is finishing
| mediocre CRUD logic as fast as possible, and taking your time to
| think will be seen as bad.
| dglass wrote:
| Shameless plug, but I've written a book about what differentiates
| a good programmers from great ones. [0]
|
| In my opinion the soft-skills far outweigh a person's technical
| skills in terms of importance when it comes to identifying
| whether is a good programmer and should be promoted to a senior
| position. Obviously the programmer needs to have strong technical
| fundamentals, but the essential soft-skills are things like:
|
| * good communication skills (speaking, writing, and also
| listening)
|
| * Reading and understanding unfamiliar code
|
| * Recovering from mistakes
|
| * Understanding how to add value
|
| * Understanding how to manage risk
|
| * Dealing with conflict in a professional way
|
| * Managing your time efficiently
|
| * So much more
|
| A lot of those things can be learned over time, but historically
| I've seen junior engineers put these things off until a few years
| into their career when they're ready to make the jump to a senior
| role, only to find that they're lacking in one or more of those
| necessary soft-skills needed to get the promotion. I've always
| advocated for juniors to start working on these skills as early
| as possible in their careers, because it will make you a better
| programmer in the long run.
|
| [0]: https://www.holloway.com/b/junior-to-senior
| gwbas1c wrote:
| > How are we getting away with this? Isn't someone going to catch
| on soon? How many "new platforms" do we have to make, before
| people start realising that rewriting everything, using "the
| latest tech" is not going to solve the problems that matter?
|
| There's a very simple solution: The tools will need to change
| more slowly. This will happen when operating systems, frameworks,
| and programming languages mature so much that it's fundamentally
| difficult to make meaningful improvements to them.
|
| We're not there yet; but perhaps its time to start working in
| that direction?
| saiya-jin wrote:
| Man, the most brilliant folks I've ever met in software dev
| realm in past 20 years were always, without exception, the
| least patient ones. They get bored very quickly with mundane
| use of stable set of frameworks and libs. Doing yet another
| similar app and not something obscure, using bleeding edge
| stuff (and bugs). By bored I mean resigning, often immediately.
|
| They are basically spoiled little brats thanx to their talent,
| and (some) companies tolerate that since they do deliver. But
| often they need to be babisitted by managers to clean any
| mundane tasks from their roads, so you sometimes have a little
| ecosystem of people or even teams working around one 10x dev.
| Mostly still worth it for the companies, but there is hidden
| price that shows often very late, ie 6 months after they leave
| and somebody has to change their brilliant cathedrals a bit.
| And one thing is as sure as death and taxes - changes will
| always keep coming.
|
| What you describe would be hell for them, they would keep
| tinkering and keep creating new frameworks, languages or even
| whole platforms just for given problem, because that's fun for
| them. That's how it all started anyway.
| gwbas1c wrote:
| > What you describe would be hell for them, they would keep
| tinkering and keep creating new frameworks, languages or even
| whole platforms just for given problem, because that's fun
| for them. That's how it all started anyway.
|
| I think at that point the people you describe will move to a
| newer field where things are still changing quickly.
| redwoolf wrote:
| What do we mean by "good" in this sentence? I've worked with
| plenty of programmers whose output a lot of code quickly, but the
| code is difficult to understand and maintain. Others whose output
| takes more time, but the solutions are elegant, well structured,
| and maintainable. Coding is a craft and assessing whether or not
| a programmer is good has as much to do with the audience as with
| any metric of quality.
|
| I draw parallels to the world of literature, sure James Patterson
| sells a lot of books, but is he a "good" writer? I would say no,
| but the millions of copies he has sold make a counter claim that
| cannot be simply dismissed.
| vbezhenar wrote:
| IMO good programmer writes code that:
|
| 1. Solves task.
|
| 2. Does that within a necessary performance constraints.
|
| 3. Uses commonly accepted approaches, libraries, style, does not
| reinvent things which are not necessary to reinvent.
|
| 4. Readable by programmers who'll work with that code in the
| future. That could be juniors or seniors, that depends on a
| particular company and project.
|
| 5. Extendable for changes which are likely to happen in the
| future.
|
| 6. Not extendable for changes which are not likely to happen in
| the future.
|
| Every item is necessary and going down this list requires more
| skill and more humility. It's easy to write complicated code.
| It's hard to write simple code which is as good as complicated
| where it matters.
|
| That's what my opinion is and that's what I strive to.
|
| That said, I might be completely wrong about it, as I see great
| churn with modern software, things are being rewritten over and
| over again. Code maintainability seems not to matter as much as
| it mattered in the past. May be that's my bubble. Sometimes I
| think that the good programmer is one who can spew JavaScript
| nonsense faster than his peers can review it, because who cares,
| that stuff is going to be rewritten tomorrow with revolutionary
| new age framework.
| mgkimsal wrote:
| > which are not likely to happen in the future.
|
| Making that determination is something you really only get good
| at with the experience of making the wrong determination too
| many times.
| ChrisMarshallNY wrote:
| _> does not reinvent things which are not necessary to
| reinvent._
|
| This is one of those "eye of the beholder" things.
|
| If I had a quarter for every time I've heard "That's a solved
| problem," with a reference to a dependency, somewhere, I'd be a
| rich man.
|
| I tend to _really_ avoid external (not written by me)
| dependencies, because I have had _many_ problems with other
| people 's code. Fixing someone else's badly written open-source
| code usually takes longer than just writing the small part of
| their library that I need, and it doesn't involve having to
| argue with them, or have my PR rejected, because I have "too
| many comments."
|
| I know that's not a popular stance, around here, but it works
| for me. I use a _ton_ of dependencies, in my work, but I wrote
| most of them.
| mellosouls wrote:
| That's fine if nobody else has to maintain your code.
|
| If they do it's difficult to see how your solutions to solved
| problems aren't going to be significantly more problematic
| and risky than established libraries.
| ChrisMarshallNY wrote:
| Not really. I'm pretty good at what I do. Feel free to see
| for yourself: https://github.com/ChrisMarshallNY#browse-
| away
|
| Most of those repos are dogfood.
| bob1029 wrote:
| This is our stance too.
|
| Even within the "batteries included" aspects of the .NET6
| framework, we insist on doing certain things our way.
|
| Some of the biggest examples being AspNetCore logging and the
| JSON-style configuration abstractions. We completely rip this
| out and do it in code-time our way. I cannot account for the
| exact number of hours we wasted trying to do [x] the
| 'official' way only to be burned at deployment & framework
| upgrade time. It took at least 100 hours just to realize
| json-based runtime config is _definitely_ not for us.
|
| Separately, it took me fewer than 30 minutes to write a
| dumbass static logger that fills a sqlite database with
| entries and have it wired up throughout the application. I
| don't think you could even read & understand that AspNetCore
| logging article in 30 minutes, much less have functional code
| in place that you can hang your hat on for years to come.
|
| If not reinventing the wheel is about saving time, then
| perhaps we need to iterate the aphorism. Maybe we flip it
| around: Only reuse other people's code when it's for
| something that you don't really care about or doesn't
| frustrate your project's long-term ambitions.
| AlotOfReading wrote:
| Reinventing the wheel can also lead to difficult-to-find
| bugs that explode years down the road. Yeah, you could
| reimplement the parts of zlib you need in a couple hours,
| but just use zlib, even if it's a core part of your
| functionality.
|
| However, as an industry we don't have a great way to know
| what is or isn't reliable. I've started publishing
| component datasheets with my utility libraries because that
| conveys the sort of commoditization I think we should
| strive for, but they haven't been very useful so far.
| ChrisMarshallNY wrote:
| _> However, as an industry we don 't have a great way to
| know what is or isn't reliable._
|
| That's the rub.
|
| Your zlib example is one of the "Platonic Ideal of
| Quality Open Source" libraries. Using that is a no-
| brainer.
|
| Any suggestion of rating/licensing/qualifying open-source
| projects, is met with ... _resistance_ ...
| jacquesm wrote:
| 5 and 6 are super hard decisions. You never really know what
| your code will be used for in the future, especially not if you
| make libraries.
|
| I _try_ really hard to do this and over the years I 've found
| myself more than once caught out by something that I wished I
| had foreseen but did not and, conversely, I have spent a lot of
| time preparing code for changes which seemed to be likely to
| happen but that never did.
| hbrn wrote:
| This is a really good point. Engineers are constantly trying
| to predict the future, but ability to do so often does not
| depend on engineering skills at all. Often it is completely
| out of your control.
|
| Instead of trying to make code "extendable" I found that it
| is much better to make code "disposable".
|
| Do not hope you'll make the right prediction. Expect to be
| wrong and be able to recover fast.
| tboyd47 wrote:
| Very nice summary here and I agree 100%.
| nine_zeros wrote:
| > 4. Readable by programmers who'll work with that code in the
| future. That could be juniors or seniors, that depends on a
| particular company and project.
|
| Underrated. Layers of unnecessary abstractions or clever
| solutions (e.g. complex types in python when simple would do)
| is a mark of a junior engineer.
| AnimalMuppet wrote:
| "Rewrite all the things in X" is how you get 1 year of
| experience 10 times, instead of 10 years of experience. It's
| also how your company burns through tons of money for little
| substantial result.
| contravariant wrote:
| While those are all good guidelines (though I'm not too sure
| about 6) a 'master' programmer should probably know when to
| break each of those rules.
|
| In the end programming is about telling a computer what it
| ought to do. Making this process as easy as possible is the
| sign of a good programmer, but there's no reason the process
| has to be limited to writing code, so talking about what code
| makes a good programmer seems reductive.
|
| Also in this view 6 is usually a mistake as it makes it
| _harder_ to communicate, not easier. That said some things don
| 't make sense, and therefore probably shouldn't look like they
| make sense either.
| jrumbut wrote:
| One of the aspects of mastery (that I've observed in others)
| is being able to say yes to 99% of requests but knowing how
| to steer projects away from that one feature that will cause
| complexity to explode without delivering commensurate value.
| Sohcahtoa82 wrote:
| > Uses commonly accepted approaches, libraries, style
|
| I would argue NOT to do this if you're writing Java. Java
| paradigms are awful, lead to way too many layers of
| abstraction, and code that is impossible to debug because your
| stack traces are just 30 calls of ".invoke()".
|
| > Readable by programmers who'll work with that code in the
| future.
|
| And yet Perl became popular.
| ben_w wrote:
| Java was the language of choice when I was at university. The
| way they described it to us, was that everything about it was
| designed with teamwork (and large teams) in mind. I don't
| know how well it really did that even by the standards of the
| era of its introduction, but it has the air of plausibility.
|
| Certainly, I expect anyone who is used to that style to
| prefer to encounter and work with Java written in that style
| over Java written in the style of C.
|
| > And yet Perl became popular.
|
| As I recall, the joke being that it was a "write only"
| language.
| Sohcahtoa82 wrote:
| > As I recall, the joke being that it was a "write only"
| language.
|
| Yeah, which is why I question how it go so popular.
| ben_w wrote:
| "Write only" means nobody works with it once it's been
| written ;)
| carapace wrote:
| It's an open secret that there's a bimodal distribution of raw
| capacity or talent for programming. (E.g.
| https://www.researchgate.net/publication/250800680_The_camel... )
|
| Anyone who can solve a Sudoku puzzle can learn to program a
| computer, and probably should, just like anybody can learn to
| read and write and do basic math (in which I include algebra,
| trig, calculus, etc.) However, there's a subset of people who are
| really good at programming, far beyond the level of the normal
| folk in the first group. (I say "normal" because the first group
| outnumbers the second by a large ratio, maybe 20:1 or higher.)
|
| The only prerequisite for being a good programmer is, in a word,
| _Logic_. If you 're good at logic you'll be good at programming,
| and if you're not, you won't. (It also helps to have a deep
| passion for it.)
|
| In re: diversity, I assume that the distribution of
| normals:programmers is fairly constant across human populations.
| Yet, there's no denying cultural/gender/race aspects affect who
| actually becomes working programmers. (I don't know what to do
| about this.)
|
| In re: all the burgeoning complexity, that's a side-effect of all
| the normals flooding into the field to make money. Up until
| roughly the Dot-com Boom programmers were largely self-selecting.
| Once normals realized they could make money using computers and
| the Internet they began to infiltrate the ranks and dilute the
| ancient hard-won wisdom of the greybeards (so-called because they
| are old, almost exclusively male, and typically very hairy. They
| literally have grey beards for the most part.) Nowadays we have
| degenerated so far that we have insanity like JS server-side!
|
| I call it "Eternal Eternal September" Most people can't remember
| or never experienced the staunchly non-commercial early phases of
| the Internet.
|
| > The point of programming is to create software that delivers
| value to the users.
|
| No, this is a _side-effect_ of programming. If logic was entirely
| useless I would still spend the majority of my time doing it. It
| 's beautiful.
|
| The fact that a large number of human problems can be solved by
| means of digital logical programs is marvelous, but it's not the
| point of programming anymore than the point of poetry is to sell
| Hallmark cards, eh?
|
| > What would the field of software development look like, if "the
| best programmers" were not the most mathematically inclined
| neophile workaholics, but rather people who are good at
| organising ( _sic_ ) work? Good at communicating clearly. People
| who care, not so much about which tools are used, but about using
| whatever tools are available to maximise ( _sic_ ) the value of
| the product being made?
|
| These folks are important and valuable. Call them Product
| Managers.
|
| Ideally, the elite programmers would write flawless efficient
| software, and the Product Managers and users would take it and
| configure it to solve their problems.
|
| (BTW, it is possible and economical to write flawless software.
| The fact that there are still so many bugs is itself another
| symptom of the primary problem: the confusion between elite
| "Real" programmers, Product Managers, and end users.)
| yodsanklai wrote:
| Is it the same thing a being a good software engineer?
|
| I've got relatively limited experience working a software
| engineer but to my disappointment, it seems more than 70% of my
| job isn't programming. Most of the work is discussing priorities,
| making tradeoffs, interacting with colleagues and management,
| writing design documents, giving feedback, writing doc,
| maintaining, benchmarking, and debugging services, learning
| proprietary tools and systems, reading documentation, figure out
| how these legacy systems work, interview candidates, mentor
| interns.
|
| Programming is in the weekend and after working hours.
| alberto7 wrote:
| This is true.
| rr888 wrote:
| The best programmers get paid the most and the best paid
| programmers do LEETCODE.
| eternityforest wrote:
| A good programmer:
|
| * Knows enough about what's actually going on under the hood to
| predict and avoid the relevant issues(SSD wear, odd cases where
| disk latency makes major slowdown, etc)
|
| * Understands the relevant details of the domain, like algorithms
| and math if they do that kind of work, or common hardware issues
| if they do embedded, etc.
|
| * Understands at least the basic level of application level stuff
| and what users expect.
|
| * Does not do anything clever unless absolutely necessary, does
| not make themselves irreplaceable, finds ways to get rid of
| anything that is slightly interesting, writes code anyone can
| work on
|
| * Avoids bikeshedding and going down rabbit holes. Doesn't spend
| 6 hours holding up the whole project because they want to mess
| with something "Really cool".
|
| * Uses stuff people already know and is compatible with stuff
| people have. Doesn't reinvent bluetooth and MQTT and .csv files
| if they don't have to.
|
| * Is comfortable using trusted libraries without fully
| understanding them, nobody fully understands every part of a
| large project, and code that already exists is likely code you
| don't have to maintain.
|
| * Is comfortable letting frameworks make decisions for them,
| doesn't try to fight the tools they use by imposing a vision of
| how things should be on them. Don't download Ubuntu and then
| complain that it's too hard to swap the init system, that's not
| what it was built for.
|
| * Doesn't secretly despise software, find ways to sabotage
| features, and wish we would all follow the guidance of Industrial
| Society and its Future.
| HideousKojima wrote:
| * Doesn't secretly despise software, find ways to sabotage
| features, and wish we would all follow the guidance of
| Industrial Society and its Future.
|
| What if I agree with the first and third parts but I don't
| sabotage features?
| gadflyinyoureye wrote:
| I'm not going to go so far as to promote violence, by I
| disagree about despising software. There is a lot of software
| out there that should/could be replaced with simple process
| changes. If you despise software enough to know that it is not
| right tool for the job even when you are a programmer, you can
| safe yourself, management and users headaches by avoiding
| writing a line.
| eternityforest wrote:
| I'm not sure I've actually seen this IRL. I've seen cases
| where new custom software is the wrong approach(Actually,
| that's most of the time), but usually it's because there's
| some existing software that can already do whatever it is.
|
| There hasn't been many times when I've seen something that
| people would normally use software for, and willingly chosen
| a process that isn't primarily software driven. I think the
| one of the only times is when dealing with physical tasks in
| personal life, I'll usually put up reminder signs like "Check
| lint trap" rather than use to-do list software.
|
| Even then I'll use my Bluetooth printer to make the sign so
| it looks nice and neat....
|
| The other case is tabletop RPGs, I've yet to see any tech at
| all that doesn't completely ruin immersion for non-scifi
| games, phones are very culturally charged objects that can
| instantly change the mood to "Screen staring club".
| alldayeveryday wrote:
| > Programming is writing down unambiguous instructions, and then
| grouping those instructions in meaningful ways. We're
| coordinating work. It's not rocket science.
|
| I think missing here is that to be a good programmer, one must be
| good at dealing with ambiguity. The output might be unambiguous
| instructions, but the input is generally anything but that.
| Working with product managers, designers, business stakeholders,
| etc - a good programmer can identify and resolve ambiguity in the
| requirements given to them in an effecting manner. This involves
| asking the right questions and often doing discovery/research.
| tuatoru wrote:
| Weinberg and Gause's _Exploring Requirements: Quality Before
| Design_ is a useful book on "asking the right questions".
|
| 1.
| https://books.google.co.nz/books/about/Exploring_Requirement...
| carvking wrote:
| technical know-how + tenacity
|
| Depends wildly on what you are doing - but tenacity in my case
| (paid consultant for lots of different companies) is my greatest
| quality. Push through - schedule carefully external dependency
| promises and follow through.
|
| Maybe this is more of a project manager answer - but a consultant
| programmer has to adopt the role of a project manager in lieu of
| a component one.
| atwood22 wrote:
| Being a good programmer can also be situation dependent. The
| ideal author for code that powers a nuclear reactor may be
| different from the ideal programmer making a consumer product.
| gorgoiler wrote:
| "New technology!" has become an existential business threat to my
| team.
|
| Some years ago the company went deep on poly repo semver multi
| components. Over time it has had provided the same long term
| efficiency improvements as putting a cup of sand in your gas
| tank. We have neither the breadth nor depth of ability to make it
| work.
|
| Good programmers, amongst other laudable traits, aren't afraid to
| delete things.
| ArcMex wrote:
| I enjoyed this article. I echo many responses here and some of
| what's in the article to reaffirm their importance in not just
| being good, but successful.
|
| 1. Clear communication
|
| 2. Thinking thoroughly about the problem and the solution
|
| 3. Easy to maintain code
|
| 4. Testing
|
| 5. Documentation
|
| 6. Research and learning
| josefcullhed wrote:
| Great article, I really think programmers should be more
| conservative when it comes to new technology. You don't always
| have to use fancy react stuff when making simple websites and so
| on..
|
| But I'm not sure about the whole "programming is simple, like
| planning a party" thing. When I am thinking about my own projects
| with more than 150K lines of code its not like any party planning
| process I have been involved in, it is actually a lot more
| complex. It is easy to forget how hard things are when you know
| them and have worked with it for many years.
| Joel_Mckay wrote:
| Communication skills, team participation, and 10000+ hours of
| practice with real-world problems. You wish that were true... ;)
|
| People often choose careers for the wrong reasons, compete to be
| at the bottom, and end up miserable. If you are over 30, the
| burn-and-churn cycle you thought would be exciting... turns out
| to be really destabilizing and lame. Consider being a plumber,
| you will make more money, and not have a student loan for years.
|
| https://www.youtube.com/watch?v=LqQlCOmXuHM
|
| To be a good Programmer, you need to fantasize about being a
| Plumber everyday. As even knee deep in sewer water, people would
| have held you in higher regard given they could actually
| understand what you did professionally.
| xwowsersx wrote:
| You sound bitter and resentful. Also, student loan debt is not
| a requirement for becoming a programmer. I have student loan
| debt, but that's because I decided to go to law school before
| switching to software development :)
| Joel_Mckay wrote:
| >You sound bitter and resentful
|
| Nope, I like what I do, and talking with the engineers I work
| with everyday. However, you are about to climb a mountain
| I've already ascended before, and can't understand my
| perspective yet.
|
| You will start fantasizing about being a plumber soon... it
| is the logical choice after all.
| xwowsersx wrote:
| I've no idea what you're talking about and I suspect other
| people you meet and interact with (at least online) will
| feel the same way. I know this might sound harsh, but
| that's my feedback in the event you're at all interested in
| communicating more effectively online.
| Joel_Mckay wrote:
| This is not an industry for the emotionally sensitive,
| sanctimonious, or petulant.
| BeetleB wrote:
| Must agree with the other commenter: It's quite hard to
| understand what you're trying to say.
|
| Also, comments like this are coming across as arrogant.
| You appear to have jumped to the conclusion that
| xwowsersx has little experience in the industry and thus
| come across as patronizing.
|
| As to your original comment: As a SW engineer, I've never
| _had_ to work more than 40 hours a week, have no student
| loan debt, and make a lot more than a plumber. If you
| find yourself forced to work a lot more, you likely have
| made poor career choices (not by picking the SW industry,
| but by picking the wrong sub-discipline and /or company).
| As such, the fact that you're doling out advice as if you
| know a lot looks even worse.
| xwowsersx wrote:
| Yeah. In fact, I have ~15 years of experience (my current
| role is Director of Engineering). I note this just to
| point out how off Joel is. I offered my feedback on the
| off chance it might be well received, but it seems
| there's more going on with him. I feel that sympathy is
| the only correct response at this point.
| Joel_Mckay wrote:
| How many companies have you worked for in the past 30
| years?
|
| Although ones history is fairly meaningless when it comes
| to general opinions. Most professions don't have a sub 3
| year Churn rate with fortune 500 companies.
|
| We can have differing opinions, and from each perspective
| believe we are correct.
|
| Have a gloriously wonderful day =)
| goethes_kind wrote:
| I just want to say, I'm really glad that we are talking about
| "programmers". I hate that stupid term, "software engineer". What
| a ridiculous title. As if programmers do not also engineer
| software. And then what are "software architects" for if you
| already have "software engineers"?
|
| Sorry for the off topic rant.
| bootloop wrote:
| In companies of a certain size the differentiation between
| these (or similar titles) get more clear. In my opinion they
| are also strongly linked with experience (in certain areas).
| jamesgreenleaf wrote:
| > That's what should matter. That's the whole point of
| programming. The point of programming is to create software that
| delivers value to the users.
|
| She's right.
|
| A good programmer makes computers do good, useful things for
| people.
|
| You could be a wizard at programming, and work to serve ads, or
| sell lootboxes, or skim pennies off high-frequency trades, but
| that wouldn't make you good.
| pards wrote:
| > I don't care how good you are at chopping vegetables, how
| efficiently you handle the ingredients while cooking or how
| modern your kitchen appliances are - if the food tastes like
| crap, I'm not coming back to your restaurant!
|
| This. Your users/customers don't care about your tech stack,
| pipeline, deployment model, or test coverage. They want software
| that works and doesn't get in their way.
|
| Your tech stack, pipeline, deployment model, or test coverage
| might support producing software that works and helps the user,
| but it's a means to an end.
| eloisant wrote:
| Yeah but if you're too slow at chopping vegetables and I have
| to wait 1 hour to get my dish, I'm not coming back to your
| restaurant either.
|
| To produce software that works and doesn't get in the user's
| way, and not introduce regressions every other day, caring
| about your tech stack, pipeline, deploy model etc matters.
___________________________________________________________________
(page generated 2022-08-29 23:01 UTC)