The field of "useful reals" between rational and real numbers (2019) - <AUTHOR> https://chittur.dev/math/2019/12/05/secret-field.html <comment><USER2> None of this is somehow secret. The standard name for this is "definable"[0]. Although, one has to be really careful with this sort of thing; there are apparently a number of subtle logical issues[1] that come up when talking about these...

(Note, by the way, that there's any number of other fields one could put inbetween; such as the field of algebraic reals, or computable reals, or the fraction field of the ring of periods...)

[0] [https://en.wikipedia.org/wiki/Definable_real_number](https://en.wikipedia.org/wiki/Definable_real_number)

[1] [https://mathoverflow.net/a/44129/5583](https://mathoverflow.net/a/44129/5583)

<comment><USER3> Well that Math Overflow post is excellent.

One of the logical issues is that there is a model of ZFC where all reals are definable/useful. I'm guessing that's not what the author of this blog post is going for...

If this seems impossible given that the number of definitions is countable, note first that it is possible that a model of ZFC is itself countable (in a larger ambient model), but it cannot witness the countability of sets within itself. So when we say that a set is uncountable in ZFC, it is sometimes useful to make the distinction that it is only uncountable in the implicit model under discussion.

Then note that definability, unlike countability, cannot be itself defined in the language of ZFC (due to Tarski's undefinability of truth result). Note that this is different from saying it's independent of ZFC. It cannot even be expressed in ZFC. Hence, unlike countability, there is no "relative" concept of definability, at least not relative to first-order ZFC. Therefore the statement "every element of this model is definable" is more absolute than "every element of this model is countable" (but not absolutely absolute, we still have an ambient model we're working in, just a richer theory for that model).

The usual diagonalization argument within our entirely definable model of ZFC to try to construct a definable real number not contained in any countable enumeration of definable real numbers fails because we have no enumeration of definable real numbers. This is not a failure of constructivism (it is ZF _C_ after all, we do have choice), but rather a consequence of the fact that definability cannot be expressed in ZFC so we don't have a way of even talking about the set of all definable real numbers within our model.

<comment><USER3> Upon re-reading my reply, it might be worthwhile to simply quote Hamkins' conclusion in full.

> And therefore neither are you able to do this in general. The claims made in > both in your question and the Wikipedia page [the Wikipedia page has now > since been updated] on the existence of non-definable numbers and objects, > are simply unwarranted. For all you know, our set-theoretic universe is > pointwise definable, and every object is uniquely specified by a property.

</comment></comment></comment><comment><USER4> The author claims in the notes that "The useful reals are similar, but not quite equivalent to other ideas in mathematics, such as [...] computable numbers."

Is that correct? What is the complement of the Computable Numbers in the Useful Reals? What is the complement of the Useful Reals in the Computable Numbers?

I've always thought of Computable Numbers as all numbers able to be represented by a finite string, ie: a computer program that would generate the number to any desired precision. How does that differ from the set of numbers with a finite symbolic representation?

Hmmmm... maybe by asking that question I've led myself to the answer. Chaitin's Constant has symbolic representations, one of which being the Wikipedia page that describes it: [https://en.wikipedia.org/wiki/Chaitin%27s_constant](https://en.wikipedia.org/wiki/Chaitin%27s_constant). Does that mean it's included in the complement of the Computable Numbers in the Useful Reals? Are the Computable numbers a subset of the Useful Reals?

<comment><USER2> The standard term is "definable", not "useful": [https://en.wikipedia.org/wiki/Definable_real_number](https://en.wikipedia.org/wiki/Definable_real_number)

But yes, Chaitin's constant is an example of a number that is definable but not computable.

<comment><USER5> Yeah I think this terminology is odd because I think that the computable numbers are much more "useful" than the definable numbers.

</comment></comment></comment><comment><USER6> If you look at the _integers_ between say Graham's number ([https://en.wikipedia.org/wiki/Graham%27s_number](https://en.wikipedia.org/wiki/Graham%27s_number)) and TREE3([https://en.wikipedia.org/wiki/Kruskal%27s_tree_theorem](https://en.wikipedia.org/wiki/Kruskal%27s_tree_theorem)) you can observe that practically _all_ of these integers, while "computable", cannot be defined within the known constraints of this universe.

Which raises an interesting question: In what meaningful sense do these numbers _exist_? They are just out of reach as the non-definable real numbers...

<comment><USER7> You're mixing up "defined" with "defined via a decimal numeral" we can define these numbers without much difficulty via finite formula that compute them. This is a completely valid definition, it is just not a decimal numeral.

An interesting idea might be "useful integers" which requires whatever definition we have to allow approximation of any finite subsequence with error converging to zero given more computational power.

<comment><USER8> GP did not mix up anything. Some of those finite formulas _also_ will be too long to be written within the constraints of this universe. The pigeonhole principle applies just as much to finite formulas as it does to finite strings of decimal digits.

</comment></comment></comment><comment><USER9> Note that like the rational numbers, the field of "useful reals" is not complete.

So if you have a sequence of "useful reals" that is Cauchy, it _will_ converge to a real number but it may or may not converge to a "useful real".

<comment><USER10> Sorry if I misunderstand you. If I have a Cauchy sequence of "useful reals", wouldn't the convergence be, by definition, a "useful real"? That is, I can write down the Cauchy sequence, so it's now symbolically noted, right?

Or are you referring to a Cauchy sequence that exists, but can't be defined using our symbology?

<comment><USER9> There are uncountably many Cauchy sequences of useful reals. You can't write them all down. So now you have to also restrict yourself to "useful Cauchy sequences of useful reals".

This is a rabbit hole with no end.

<comment><USER11> > There are uncountably many Cauchy sequences of useful reals. You can't write > them all down.

This does not hold if you demand that, for example, the map

k -> a_k

that represents the Cauchy sequence, is a computable function.

<comment><USER9> I am a bit shocked, because that seems like a really dishonest way of doing things. "Surprise! Actually, I am not talking about Cauchy sequences, but only computable Cauchy sequences."

If you change the rules you had better be up front about it.

What you are describing is a _completely different definition_ for "complete metric space" than what is commonly accepted by the mathematical community at large. So do not be surprised that by using different definitions, you come to different conclusions.

<comment><USER11> > I am a bit shocked, because that seems like a really dishonest way of doing > things. "Surprise! Actually, I am not talking about Cauchy sequences, but > only computable Cauchy sequences."

Rather: If countability is important to you, you should change the rules so that the property that the field is closed w.r.t limits of Cauchy sequences does not make your set uncountable.

Redefining the rules if something does not work is how you do mathematics works all the time:

\- A PDE does not have a solution in a classical sense and you hate this? No problem: You invent the theory of weak solutions and distributions and simply change the concept what is to be considered a solution of the PDE.

\- The concept of algebraic varieties turns out to be to limiting to obey the rules that you would love them to have? No problem: You define the concept of algebraic schemes and now talk about algebraic schemes instead of varieties ([https://en.wikipedia.org/w/index.php?title=Scheme_(mathemati...](https://en.wikipedia.org/w/index.php?title=Scheme_\(mathematics\)&oldid=942687770)).

TLDR: Mathematics is often the art of "defining your problems away".

<comment><USER12> _> If countability is important to you, you should change the rules so that the property that the field is closed w.r.t limits of Cauchy sequences does not make your set uncountable._

Ok, fine: I hereby declare that the set Q of rationals is a closed field, because I define "closed" to mean "closed under Cauchy sequences whose limit points are rational numbers".

Does that seem OK to you?

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> A nit:

"reals are a field extension of ℚ. They could be considered an algebraic number field..."

This is not an algebraic extension. Pi is a "useful real number" and it is not algebraic over Q.

<comment><USER9> Yes—and to elaborate, the reason why an algebraic field extension of ℚ cannot contain π is because:

\- If it is a field, it contains π, π², π³, … which are linearly independent.

\- By definition, an algebraic field extension is finite dimensional.

<comment><USER14> You are wrong! The algebraic field extension ℚ[π] contains π.

<comment><USER15> I guarantee that is not an algebraic extension.

It's not even a finite extension

<comment><USER16> That's not a valid critique, as other commenters explained

<comment><USER15> You're totally right, I could have worded that differently. I actually posted an infinite field extension that is algebraic elsewhere in this thread, but usually those are tricky and I haven't seen them pop up as often as finite algebraic extensions

</comment></comment></comment></comment></comment></comment><comment><USER17> Not "between" in the sense of having an intermediate cardinality between rationals and reals, since they are exactly the numbers available from strings in some symbolic system or other. Seems to be a slightly expanded case of algebraic numbers, since additional forms (like infinite definite integrals) are allowed.

<comment><USER18> Yep, that's right. Its cardinality is the same as rationals, since it's countable.

<comment><USER19> How disappointing.

Unlike most of the time, I read the article first and now that I'm here, that was the question I had - clearly it's smaller than reals, but how and why is this field larger than rational numbers? Guess it's not.

<comment><USER9> It's larger than the rational numbers in the sense that it is a strict superset. Cardinality is what a lot of people reach for when they are talking about "larger" or "smaller", but there are lots of other useful concepts which we can translate to "larger" and "smaller".

So when someone says "larger" or "smaller", your first step might be to try and translate that relationship into a more precise mathematical concept, like cardinality or measure.

Casual terminology also leads to weird discussions. Like when someone asks whether some function is "close" to another, and these functions are defined in terms of vector spaces. Unfortunately, "closeness" does not necessarily exist in a vector space. So the answer may be that the question does not make sense.

<comment><USER20> > "closeness" does not necessarily exist in a vector space.

The asker will give a definition. For example, two vectors are close if sqrt of dot product of difference of the two vectors is smaller than some number delta.

</comment></comment></comment></comment></comment><comment><USER21> > A "useful real" is just a real number that can be precisely described (not > just approximated!) by some symbolic notation. Obviously, this definition is > loose and depends greatly on your choice of symbols and their definitions.

In fact, the definition is necessarily loose. If you could make it precise then you could carry out Cantor's diagonalisation procedure to produce a precise description of a real which couldn't be precisely described, a contradiction.

<comment><USER22> > the definition is necessarily loose. If you could make it precise then you > could carry out Cantor's diagonalisation procedure to produce a precise > description of a real which couldn't be precisely described

Is this true without the Axiom of Choice? Don't you need a choice function to order the numbers before you can diagonalize them?

<comment><USER16> Finite descriptions are countable. Axiom of Countable Choice is not counterintuitive like Axiom of (Uncountable) Choice.

You can order the set of all definitions, by prepending each definition with its length and then using the ordering (numerical order, alphabetical order).

<comment><USER21> That doesn't even need Countable Choice. You only need any form of Choice when you can't explicitly specify an order, which you did.

</comment></comment></comment></comment><comment><USER23> Aside from all the other issues people have raised, equality is not decidable for the "useful reals". While they form a field, they do not form a computably-ordered field, which makes them quite a bit less useful than many other number systems.

</comment><comment><USER24> Another related topic of interest is constructivism in mathematics. Unfortunately the wikipedia article is pretty abstruse, anyone have a more down to earth one? [https://en.wikipedia.org/wiki/Constructivism_(philosophy_of_...](https://en.wikipedia.org/wiki/Constructivism_\(philosophy_of_mathematics\))

(Note this is different from constructible numbers, which the author mentions. That has to do with classical geometry.)

<comment><USER25> My favorite is the collection of essays touching on the topic in the book *The Mathematical Experience".

All of the other essays in the same book are also good. :-)

</comment></comment><comment><USER26> The premise of this idea - that anything describable can be written in a binary firm and is thus countable - seems wrong. It's wrong because we easily invent new concepts and put them into a symbolic form. We could invent a new concept, agree on a new symbol for it and add it to our alphabet. The set of ideas isn't countable and so our alphabet isn't countable. This alphabet can't be translated into some binary form either.

<comment><USER27> Why is the alphabet not countable? If each time you think of a new idea and make a symbol for it, I can also assign it to an integer (because there is always a next integer like there is always a new symbol you can come up with).

When you come up with a new concept, it should also be possible to write out a definition of it. If you can write down your definition (in English, math notation, etc.), then it comes from a countable set, since there are countably many things that you can write down.

<comment><USER26> We don't "come up" with ideas from other ideas using some closed form rules of logic, like in Coq or some Turing machine. Instead, we discover new ideas.

There is a world of ideas and the real world. People live in both worlds. When they discover a new idea, often by accident, they label it with a symbol and use it in the real world. Other people can see the same idea and since they can't fully describe it with words, they agree to use the new symbol.

We describe new concepts with words, but those definitions are underspecified: they refer to things with vague or non existent descriptions, or just common sense. What is "set" for example? The same words often mean different things in different contexts. This extra meaning that's always attached to words is what makes these definitions non countable.

<comment><USER27> Even if ideas come from an uncountable set (not convinced yet), there are still only countably many ideas people will ever have. Each time anyone comes up with an idea, I can assign it a new integer.

<comment><USER26> Im merely trying to drag the concept of separating ideas and reality as two different but very real worlds under the spotlight of everyone's attention. This concept is fundamental and very old. I won't be able to defend this idea with formal proofs.

</comment></comment></comment></comment></comment><comment><USER28> Many sets have a "useful" subset this way. Even the class of all sets have a "useful" subclass.

</comment><comment><USER16> Such a weird perspective. The author thought they discovered something that true and interesting and kind of fundamental but wasn't already published, but didn't think it was worth publishing to the math community?

<comment><USER29> Thinking about maths is fun, and some people do it for leisure and write what they find in innocuous places like blogs. Usually the things you come up with are already well-known by a different name (as was the case here), so one would usually not publish something like this.

Think of it just like a random blog post on someone's thoughts. Just because it contains maths doesn't mean it needs to be published or not, it can be free to live its own life.

</comment></comment><comment><USER30> this reminds me of unit testing, where the tests come up with arbitrarily defined numbers, and the function you test tries to come up with a consistent way to count them. If you can change your function each time a test is added, the tester never wins. Isn't this similar? It seems like cherrypicking to include simple formulas with e and pi in your numbering system.

</comment><comment><USER31> Does this field behave differently from Q in some 'useful' way?

<comment><USER32> It has sqrt(2), for starters? Not sure what do you mean by useful.

It is not "useful" in the sense that reals are most "famous" for: it is not complete. Cauchy sequences can diverge in the useful reals field.

<comment><USER16> Completeness in the "full" reals is a useless feature, though. All is gives you is an emotional crutch to pretend your cauchy sequences can be mapped to regular numbers. But it doesn't give you anything you didn't already have in the cauchy sequences and useful reals.

<comment><USER33> You are of course right, reals are isomorphic to equivalence classes of Cauchy sequences on Q. But once you are dealing with equivalence classes of Cauchy sequences on Q you might as well give it a name. Maybe call it R.

<comment><USER32> His point is different. You cannot (by definition) ever write a "name", a formula, a rule, a lim expression, anything really, for a real that is not in the useful reals.

</comment></comment></comment></comment></comment><comment><USER34> it's good to see the "real numbers are fake" crowd out in full force!

<comment><USER16> Ahem.

Repeat after me, the Creed of Numbers:

" The imaginary numbers aren't imaginary.

The real numbers aren't real. "

</comment></comment><comment><USER35> There is well defined name for "useful reals": Algebraic numbers. Of course the well-definedness necessitates some limit on how the symbolic description looks like (ie. algebraic numbers are roots of polynomials with rational coefficients) because every real number can be described by some arbitrarily complex symbolic notation.

Edit: I vaguely remember that there used to be some name for the intersection of algebraic and real numbers, but I neither can remember it nor can find it on wikipedia.

<comment><USER36> > every real number can be described by some arbitrarily complex symbolic > notation

This seems like it would have to be false, because otherwise the reals would be countable (iterate through every possible 1-character string, then every possible 2 character string, then 3 chars, etc and in a finite (but potentially very very large) amount of time you would come across the description of any real number that can be described).

</comment></comment><comment><USER14> The author claims that this set is countable but not sure if that is true. My argument is based on Cantor's theorem [1], which states that the power set has cardinality strictly greater than the set.

In order for the set of symbols to be finite field it must grow therefore since rational is infinitely countable from Cantor it must hold that "useful reals" is uncountable.

[1] [https://en.wikipedia.org/wiki/Cantor%27s_theorem](https://en.wikipedia.org/wiki/Cantor%27s_theorem)

<comment><USER37> If you have a finite set of symbols, then the set of finite sequences of those symbols is countable. The key here is 'finite sequences', if you were to allow for infinite sequences then the set if uncountable.

</comment></comment><comment><USER38> This is one of my favorite obscure math topics.

I think of the "useful reals" being the "reals that have names". Alan Turing developed the Turing machine to get a handle on the "useful reals" since you can make a Turing machine write them out one digit at a time.

Given that, I don't like the term "real numbers" at all because they are phony compared to the "useful reals" \-- if you reject the axiom of choice then the construction that Cantor does to construct a real isn't valid.

Despite calling for a rebuild of math and science based on computation, Steve Wolfram has yet to take the critical step of rejecting the axiom of choice. I wish he would man up.

<comment><USER21> > if you reject the axiom of choice then the construction that Cantor does to > construct a real isn't valid

Are you talking about Cantor's argument that the reals are uncountable? That doesn't need choice.

<comment><USER22> Elaborating, the hypothesis that Cantor disproves is "The real numbers are countable -- that is to say, the real numbers can be put into one-to-one correspondence with the natural numbers".

You never have to use the axiom of choice, because the hypothesis tells you there is a one-to-one function between the reals and the naturals. You can then order the reals in the order suggested by their image in the naturals: f(0), f(1), f(2), ...</comment></comment></comment>


Tepco releases badly altered image of Fukushima Unit 4 - <AUTHOR> http://enenews.com/tepco-releases-badly-altered-image-unit-4-photo

<comment><USER2> Hi, I'm a physician who deployed as part of the US military response, specifically, I was in the contingency planning cell. Assuming there is a hole in the wall, which is a curtain wall, not a containment wall, then it leads to work areas around and outside the base of the reactor containment vessel. The presumed hole is above the wet well and may or may not be on the side facing the containment pool.

If it is on the side of the containment pool, the wet well may not be covered by a floor (I have seen conflicting schematics on this). However, Unit 4's primary issues were with their spent rod pool. If that is involved, there are two concrete decks between the bottom of the pool and the space exposed by presumed hole.

So, my guess is the wet well may be exposed by that hole in the curtain wall, and may or may not have any damage, but the wet well is definitely failed in Unit 2, and I can see where they wouldn't want people whooping and hollering about wet wells. I'm sure the insides of that are a complete mess at this point. Even if this was a normal construction site, it would be a complete mess at this point.

I see others have mentioned there may be a truck access tunnel at this spot. Perhaps, but I'm unclear as to the orientation of the 4 sides, and that seems a bit irrelevant to the reactor.

Meanwhile, the NRC daily updates petered out long ago. I'm not planning any trips to Fukushima any time soon.

Update: here is a great presentation we got from Areva. Glad to see it's available to the public:

<https://wikispooks.com/w/images/5/5d/Fukushima-areva.pdf>

<comment><USER3> Ok, so assuming all that is true, why obscure the hole?

I can still recall during my sentiment during the unfolding of the Fukushima incident. The whole time, I kept reassuring everyone to keep calm and not assume the worst because the information coming out of TEPCO indicated that the reactor was "OK". Heh, boy did that turn out to be a mistake.

So, what we have here is a situation where TEPCO has dropped a nuclear bomb on their credibility. Normally, I'd give them the benefit of the doubt and assume that all these are perfectly plausible explanations worth considering, but after the way they handled the incident as it was occurring, I'm not inclined to believe anything not seen or verified by my own eyes or trusted third- parties.

A doctored image coming from TEPCO gives us every reason to be alarmed. Given their past behavior, it's a good indication that something is amiss.

<comment><USER2> > something is amiss

I'm not arguing that point. All I'm saying is, whatever is going on, I don't think I'm going to get called back over for contingency operations. The joint task force never disbanded, we're all theoretically still on call for this. As far as TEPCO's relationship with the Japanese people, that is a situation for them to resolve internally. My brother's wife is from Ibaraki prefecture (between Tokyo and Fukushima). He plans to make a career of law in Japan. But I seriously doubt we will see any new catastrophic developments or American tax dollars spent on the problem.

</comment></comment></comment><comment><USER4> I don't know how this makes me feel.

Should I be upset, because a company aims to purposely lie to the public?

Should I be happy, because any sufficiently large organization will inevitably make stupid mistakes like this one?

Or should I be terrified, because it's likely that better-done versions of shit like this is done by supposedly trustworthy corporations and governments every day?

<comment><USER5> If everything were okay TEPCO would have a lot to brag about and its image would only go up.

It's no wonder so many rank and file TEPCO employees are resigning of late. [http://www.japantoday.com/category/national/view/tepco- worke...](http://www.japantoday.com/category/national/view/tepco-workers- quitting-due-to-threats-sense-of-despair)

I bet they know more than the general public does too.

</comment></comment><comment><USER6> Maybe they made that area blatantly obviously shopped in order to direct attention from more important, well shopped areas of the photo.

<comment><USER7> You're very good at conspiracy theories.

<comment><USER8> Perhaps the photo is designed to distract from other better shopped photos at better hidden accidents in better hidden countries.

</comment></comment></comment><comment><USER9> They can't even lie competently. Where are the organizations competent to run a nuclear power station? Because nuclear power, done right and engineered well, is the one of the safest and best sources of energy. Tepco is criminally* incompetent, however, and this makes it hard to make a case for nuclear power when their gross incompetence is stinking up the joint.

* Have any Tepco execs been charged? They should be...

<comment><USER10> "Because nuclear power, done right and engineered well, is the one of the safest and best sources of energy."

Here's the thing: most human endeavors are going to be done wrong and engineered poorly at some point. If I run a slipshod coal-fired plant I can give cancer to a bunch of people and blow up a town, but I'm not going to threaten the food production of an entire country and possibly an ocean.

Warren Buffett has famously said (I paraphrase) that he only invests in companies that will do OK even if managed by complete idiots for ten years because most companies will be managed by idiots for extended periods of time.

Basically, you want to move to Theory, because that's where nuclear power plants are a great way to generate power.

<comment> Tuna-Fish Here's the thing: Even a completely perfectly managed coal plant does more damage over it's operational lifetime than the nightmare scenario at Fukushima.

Yes, the damage done by the coal plant is more diffuse. But it is not less than the damage done by Fukushima to the ocean and to eastern japan. Coal plants worldwide kill half a million people per year from direct effects, and a lot more from indirect ones.

Also, the nightmare scenario at nuke plants is commonly overstated. Fukushima did not, and cannot, threaten the entire food suppy of Japan. If all it's radioactive isotopes were evenly laid out on all of its fields, the concentrations would be small enough that eating the food would be bad for you, but no worse than breathing the air full of SO4 and NOx found in places where coal plants are run badly (like china).

<comment><USER11> With coal, the danger is roughly where the profit is. You use cheap coal power? Please have your increased risk of respiratory disease that comes with it. One can make policy based on those risks, and given a democracy, people can choose.

With nuclear power, you have a low probability of a very catastrophic event with consequences that aren't local. In a very simplified scenario, 50 countries can carelessly operate a nuclear power plant each, and only one of them blows up. However, the wind carries the fallout to another country that never used nuclear power. The people who get cancer, whose soil is irradiated, never saw any benefit from nuclear power, and they never had a chance to stop the plant being built, because it was outside their jurisdiction.

So please, could we finally stop comparing Black Swan-type events with non- local consequences to managable, local risks?

<comment><USER12> Coal is not a "manageable, local risk"; coal causes problems with probability ~1.

Also, the average coal power plant produces more radioactive waste than a nuclear power plant.

The real problem: people fail statistics. People can easily observe a nuclear plant when it shows up on the news, and assign a disproportionately high risk to it. The ongoing damage of coal plants doesn't make the news, because it falls under "day-to-day operation" rather than "disaster".

<comment><USER13> Nuclear plant failure statistics are meaningless as a measure of safety. You are pointing to the nonoccurrence of a rare event as evidence of its rarity.

Even if coal plants cause more damage to the world, failures are local and manageable. When your nuclear plant fails catastrophically, as they have at Chernobyl and now Fukushima, you can't point to "but this is a six-sigma event!" as an excuse. Given this risk, fission plants have been neither economically nor environmentally preferable enough to displace other ways of generating electricity.

</comment></comment></comment></comment></comment></comment><comment><USER14> Maybe they just removed some company's logo? Bad public image and stuff..

Instead of covering it with a black rectangle, they stamped it with a similar color, some people went all conspiracy.

<comment><USER15> Pretty odd place to put a logo.

<comment><USER16> It looks like there is just a hole in the wall there:

<http://photo.tepco.co.jp/library/120120_2/120120_10.jpg> <http://photo.tepco.co.jp/library/20120810_01/120810_01.jpg>

(The damage lines up pretty well across those photos)

Doesn't really explain why they masked it out though.

</comment></comment></comment><comment><USER17> Looking at older images of reactor #4, there should be a hole in the wall were the altered area of the photo is. In older images, there is what looks like a truck entrance, that extended out from the reactor building, and this has since been removed. Perhaps Tepco did not want people to see a gaping hole in the side of building.... you can see the truck bay that is no longer there in this photo.. <http://cryptome.org/eyeball/daiichi-npp/pict12.jpg>

</comment><comment><USER18> That is about the most shoddy photoshop job by a $10B corporation ever.

Anyone have any ideas what was in that corner they might want to hide?

<comment><USER19> I was able to find a video [1] of the building, with that area visible to some extent. You can see it at various points, like at 3:43. I'm not sure of its significance though.

[1] <http://www.youtube.com/watch?v=NX59-ZBO3mo>

<comment><USER20> Looks like a door/access of some kind.

Edit: There was some kind of entrance tunnel connecting there : [http://exposingthetruth.info/wp- content/uploads/2012/05/fuku...](http://exposingthetruth.info/wp- content/uploads/2012/05/fukushima_4.jpg)

Still not clear why they'd shop that.

Edit 2: this article has more details : [http://translate.google.com/translate?sl=fr&tl=en&js...](http://translate.google.com/translate?sl=fr&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fgen4.fr%2F2012%2F09%2Ftepco- camouflage.html&act=url)

It's the entrance of the tunnel from which fuel is normally loaded.

</comment></comment></comment><comment><USER21> A more interesting question is why they did their photoshopping in MS Paint.

</comment><comment><USER22> Whoever edited this image had ZERO experience with image editing. I think that's an interesting point to consider. It isn't that the person was bad, the person was _untrained_.

A bad graphic designer, say someone who dabbled in photoshop over high school and has no real artistic talent, would have done a better job.

I feel that is an important point because (getting rather tinfoil-hatlike) it leads me to believe the person that took the picture, or a very small circle of individuals, decided to alter the photo. This wasn't a big group-think decision, this was a few people who felt they couldn't talk to anyone else about this, not even pay someone $100 to do a semi-decent job out of fear of the originals turning up in the wrong hands...

or maybe it was just a timestamp embedded on the picture and they didn't want it shown. Who knows.

</comment><comment><USER23> We should not accept, that a company that can kill us all just with a little mistake, lies to us notoriously.

<comment><USER7> Kill us all? Exaggerate much? Even if they tried they couldn't kill all that many people.

And lots of companies can cause massive deaths. Dam operators for example.

<comment><USER20> TEPCO owns and operates quite a few dams : [http://www.tepco.co.jp/en/challenge/energy/hydro/p-plants-e....](http://www.tepco.co.jp/en/challenge/energy/hydro/p-plants-e.html)

</comment></comment></comment><comment><USER24> Looking at the homepage of enenews.com, it looks like the website has a pretty strong bias. I wouldn't put much stock in this photo, in fact I doubt Tepco doctored this image themselves.

<comment><USER25> The original is hosted on Tepco's website[1] and Google-translating the article[2] suggests that it is purported to be an actual photo.

[1]: <http://photo.tepco.co.jp/library/20120830_03/120830_28.jpg> [2]: [http://translate.google.com/translate?sl=ja&tl=en&u=...](http://translate.google.com/translate?sl=ja&tl=en&u=http%3A%2F%2Fphoto.tepco.co.jp%2Fdate%2F2012%2F201208-j%2F120830-03j.html)

<comment><USER24> Fair enough. Still, it doesn't look like enenews is the place to go, to get balanced, objective reporting.

<comment><USER26> I would trust them more than Tepco.

</comment></comment></comment></comment><comment><USER27> What could they possibly want to hide in a photo that already shows the wreckage of a nuclear power plant?

<comment><USER16> The most likely thing, to me, is some piece of equipment that they agreed not to publicize.

So one way of looking at it is that they chose to release the rest of the photo.

<comment><USER2> > some piece of equipment that they agreed not to publicize

exactly

<http://news.ycombinator.com/item?id=4471850></comment></comment></comment>


Ask HN: How do I get my team to write better code? - <AUTHOR> I'm leading a team of programmers - not all of whom I had a say in choosing. They're generally a smart lot when it comes to understanding the algorithmic & functional logic - but make beginner level mistakes like hardcoding thigns, naming functions like "findeventsfromthelast6hours"  (when the 6 hours could be changed at some point - rendering the name of the function pointless). And so on...<p>I review commits now and then and find some of these issues - but due to the nature and timeline fo the project cannot do it for each and ever commit of course. So I'm wondering what  I can do about this? Is there a short guide or book that I can recommend my team to read? I of course tell them these things myself too - but it gets frustrating because I keep feeling like a lot of this should really just be common sense. <comment><USER4> You need to stop thinking of them as 'coders'. When you think of them that way, you're putting them in a box and limiting them.

Instead consider them to be a team of people. As you said, each of them are at different stages in their career in programming. You need to understand this and sympathize with them and their code. This takes time and effort on your part to help lead the way.

You say that you review the commits now and then and find some of these issues, but do you bring them up? Do you show them how the code can look and read better?

If you do, make this a process and act as the person approving pull requests for the first several weeks. Then formalize this process and delegate this job to the next person who you feel writes high quality code.

Again a SHORT guide or book will not turn around the quality of your codebase and the team working on it. If you're interested in better code, invest in your team. Send them to conferences, give them a budget to spend on books, have book clubs and lunch and learns. Invest in the process of improving the skills of your team.

<comment><USER5> I agree with this other than the lunch and learns. Leave their one break in the day out of it.

<comment><USER6> Heh... have a bad experience with lunch-n-learns at a previous gig? :)

Pretty much everything in this comment thread describes approaches that only work with the buy-in and support of upper management. If OP (or anyone else) is truly in a position where code reviews are impossible, and lunch is everyone's "one break in the day", then there is very little you can do improve code quality in that environment.

In THAT kind of environment... you slog through, get what you can onto your resume in preparation for the next job search, and don't let yourself get too emotionally attached. Support for quality has to start from the top, you really can't "grassroots" it if upper management pays only lip service or doesn't really care at all.

</comment></comment></comment><comment><USER7> There are many different things you can do, but it all comes down to: do your programmers care? If they don't at all, it will be impossible to make them improve. If they care a lot, they will improve themselves. If they care a little, that's where you can try some of the strategies others have given here.

As for my specific suggestions, I would recommend "The Pragmatic Programmer: From Journeyman to Master", and actually apply the principles in the book yourself. Use unit tests, setup CI (such as Jenkins), a code review system (such as Gerrit), a bug tracker, code analysis (such as Sonar), and use tools (linters, etc). Also, cranking up warnings on your compilers/interpreters and not allowing in anything that doesn't pass muster is a good start. This might all seem like a lot, but you can do little parts of it at a time. It is worrisome that you say you can't review every commit. Perhaps you could assign members of your team to review each other's commits? This would also have the bonus of giving them a feel for what it's like to be on the receiving end of bad code, and to teach each other.

</comment><comment><USER8> _I review commits now and then and find some of these issues - but due to the nature and timeline fo the project cannot do it for each and ever commit of course._

Why not? I do.

I have 8 direct reports and I review every single line of code that they write. Some days this is all I do.

Others think I'm crazy but our group outperforms every other group by any measure. I'm convinced it's because of peer review.

A few thoughts:

1\. Regarding resources and timelines: It's not when you start, it's when you finish. Every hour of peer review saves me at least 10 hours on the back end (systems testing, regression testing, user acceptance testing) and 100 hours on the back/back end (maintenance).

2\. I never have to tell anyone anything more than once. I make sure I explain why. (When you do <x>, you cause <y>.) Then they learn and remember. This is not a religious debate; it's a way of conducting business. This won't work nearly as well if people are more interested in showing what they know than learning how to do it properly.

3\. As I get to know different people, I know where I can skim and where I have to focus. I rarely return much to senior people. I often return a lot to junior people.

4\. Everyone makes mistakes, even senior people, and even me. Peer review, like regression testing, is a pain in the ass, but it more than pays for itself on the back end.

5\. As soon as you feel you're ready, you're senior people can take some of the peer review workload. I have done this before, but it hasn't lasted because of turnover.

6\. Once people know everything will be peer reviewed, they become more careful about what they're doing.

7\. Technical debt is a huge timebomb. I know of no better way of slowing it down than 100% peer review.

8\. Everything is documented in the ticket. This provides some feedback on how it's working and what should be changed (programming standards, peer review methods, etc.)

9\. Once you put your phone away, get off the internet, and stop going to useless meetings, it's amazing how much more time you have to do things that really make a difference, like peer review.

10\. I hate doing this. I'd rather just code. But the only thing I hate more than peer review is fixing bugs. That's why I do this.

<comment><USER9> +1

100% peer review is the _only_ process change that has been implemented anyplace I've worked in the last 18 years that seriously and lastingly improved code quality. I don't like reviewing, but it's very _very_ effective, especially once you get good at it (and, like anything, it takes practice) - also, fwiw, it really improves you own coding

<comment><USER10> I agree completely and I would add that you need to keep the review size reasonable for this to work. I've been asked to review thousands of lines of code at once and it doesn't take long before your eyes glaze over and you start missing things.

</comment></comment></comment><comment><USER11> I wrote a short blog post for work about this [http://blog.cloudflare.com/making-code-better-with- reviews/](http://blog.cloudflare.com/making-code-better-with-reviews/)

Simply put: we use git and developers can't commit to the master branch. They commit to their own branch, the build system builds/tests that branch and the developer makes a pull request and gets the code reviewed.

<comment><USER12> I enthusiastically second the suggestion to use pull requests. They make a huge difference in my experience, for a few reasons:

1) You're more likely to catch bugs, security issues, and potential performance problems before they get into your main branch.

2) Your developers will get feedback on their code, which is hugely important to growth (you can't learn from your mistakes if you don't know you're making them).

3) Your developers will learn how to _give_ feedback, and how to have constructive discussions about code by virtue of reviewing and commenting on pull requests.

4) I think there's some light, healthy social pressure when you know that other people are going to be doing code reviews. People seem to be a bit less likely to take the "easy" (read "hacky") way out of a problem when they know there will be eyes on their code.

My experience has been that most developers really _like_ getting feedback and having these discussions. And I've definitely seen them pay off.

</comment></comment><comment><USER13> We do team based pull request reviews. (in github)

You need two other seniors to give you +1 to move on. The number "two" comes from the fact that we are still a small team.

People can will still review stuff that has already two +1's but the commiter could already move on if needed.

The advantage of pull requests is less "teaching how to do it properly" but more "learning from each other" and "continous exposure to all parts of the codebase".

Thus it's not the job of the Team Lead to do this reviews but everyone's.

Pull requests reviews are done (asynchronously) done each morning (whatever this means for each person/timezone). This leads to the fact that you usually can expect PRs to be done within 12-36hours.

I could not imagine working in a team with different experience levels (not speaking of countries/timezones/specialisation) without pull request reviews.

<comment><USER14> This is a good process and works well for my company as well. Everyone does code reviews but you need 2 senior people to call it complete and check it in.

The other part is encouraging them to be engineers, not "coders". Coding implies write code and shoot it out. Engineering is a mindset of continuous improvement and complete examination of the problem and solution.

</comment></comment><comment><USER15> We do 1-1 peer reviews and make changes in real-time so that the developer can see the preferences for code style, naming, indenting, etc.

You should also lead by example. Your post includes numerous spelling and grammatical errors. If you want them to be precise with such things, you yourself must do the same. Sorry, not picking on you, but your developers will follow your lead with any form of writing.

<comment><AUTHOR> Right, well it's one thing when posting on HN - I'm not really running a spelling and grammar check. That said - my complaints are not around their writing style. Many of them are non-native speakers and I can live with bad grammar & spelling in comments. The pain-point is really the coding style that leads to bugs where they could have easily been avoided.

I do get your general point of leading by example though - and like the idea of "show them whats wrong instead of just telling them by fixing it in real time".

</comment></comment><comment><USER16> Apart of the suggestion here, you have a problem in " but due to the nature and timeline for the project cannot do it for each and ever commit of course".

If the time is so tight that you can dedicate time to fix stuff (including the code quality) then any of the suggestion here are DOA.

Remember: If you want to chop wood for 10 hours, use 8 to sharp the axe.

Code, code, code, code non-stop is as efficient as chop wood without sharp it after a while.

Dedicate time to improve the code quality _ALWAYS_ pay off. Think: "I'm time constrained, so continue the death march until we finish" ALWAYS make the project _take longer_.

\---- A good idea is STOP each week, review the tasks, ask where are the pain, where is the code that is becoming a mess, what is complicated, then FIX that. Decreasing code/clearing it in the short AND long run will be a time saver.

Encourage change when the purpose is quality. Not stick to code/design that is a pain. Stop each week to breathe and see if move forward as now make sense, or is better to kill a portion of the code and rework it.

This is specially important when the TIME is critical. When time is not critical, you can do bad code because, hell, you can take the time! But when you have not time, any bad code is slowing you.

Then make this clear to the team.

Not be yourself the only that code review. Everyone can do it.

Take control when deploy. Not when your customer say so. Be predictable (ie: Always deploy in the start of the week, never at the end).

</comment><comment><USER17> I think you can get a long way with "automated code reviews" \- basically, linting and static analysis. There are various ones out there for your language - disclaimer: I wrote one for Python called [https://landscape.io](https://landscape.io)

They can take a little while to get set up exactly how you like them, but once you do, run them on your CI server after every commit and it'll output the warnings about style violations and so on. That's basically what you're after. It's not a replacement for a manual code review but it's certainly closer to what you want than nothing!

As other have said though, this only works if you and your team treat code quality as important and actually take the time to understand the output of the analysis tools. That's why I like the CI approach, so that you can see if the number of warnings is going up or down over time and react accordingly. That metric is a useful one to keep an eye on to get a view on the quality of your code, and if it gets too high you can schedule some time.

(PS if you are interested in learning more about "Automatic Code Reviews" for Python, here's a talk I did at EuroPython14: [http://carlcrowder.com/pages/europython-2014-automatic- code-...](http://carlcrowder.com/pages/europython-2014-automatic-code- reviews.html) )

<comment><AUTHOR> this is great - I love coding in Python and would definitely use this in the future. Currently we're doing everything in Node.JS though - do you know of any tools for that ? We do use Jslint etc - but landscape certainly seems to go a step further..

<comment><USER17> You should check out [https://codeclimate.com/](https://codeclimate.com/) then, they support JS and Ruby. There's also [https://scrutinizer- ci.com/](https://scrutinizer-ci.com/) who do PHP and apparently Python and Ruby now too.

<comment><USER18> [https://www.codacy.com/](https://www.codacy.com/) supports JS, PHP, Scala, Python and CSS

</comment></comment></comment></comment><comment><USER19> Honestly, the things you describe are not that bad. If they are writing code that passes the test cases, move on and be happy. If you'd described things like circular dependencies and passing brittle "magic strings" through multiple layers -- things that will GENUINELY cause maintainability issues I'd sympathize more.

I doubt anyone named it the "...last6hours" but then parameterized the number of hours -- so you're changing that code anyway if the number of hours changes. If you have a requirement to parameterize that, do so, otherwise YAGNI, move on.

Hardcoded strings is another one. Frankly, unless you are using the string in more than two places or it's part of a "set" of values, where referencing the full set is useful, you may just be making more work to do it 'correctly'.

You reference timeline pressure. "Good, Fast, Cheap, pick two". If you don't have enough programmers for the timeline alotted, the powers-that-be have already selected Cheap and Fast. Deliver a product that does the job asked, a few maintenance iterations (if the product is one of the 30% that make it that far) will teach you want areas of code are touched a lot and need to be "made maintainable"

<comment><AUTHOR> Thanks - while a lot of the other advice on this thread is helpful in terms of being a better team lead in general - I think the stuff you mentioned is really what I can apply almost immediately - especially the last bit about makign things maintainable.

</comment></comment><comment><USER20> Give them a free copy of Clean Code[1], I started to care about my code more after I read that book.

You cannot sit and review each commit, the best you can do is to make them care about code.

[1] [http://www.amazon.com/Clean-Code-Handbook-Software- Craftsman...](http://www.amazon.com/Clean-Code-Handbook-Software- Craftsmanship/dp/0132350882)

<comment><USER21> Any chance I get I make an effort to suggest this book. There is also another book by Robert C. Martin which I suggest called The Clean Coder[2].

[2][http://amzn.com/0137081073](http://amzn.com/0137081073)

</comment></comment><comment><USER22> Saw something interesting at a conference a while back. If you have a few days, it might be worth trying. It's called "mob programming"

Basically you get everyone in a room. The basic premise here is that everybody brings their "A game" and shares it with everybody else. One person types, everybody else decides what to type. Sounds chaotic, but as long as folks stay focused, what happens is that very quickly the entire group gets on the same page about IDE, coding standards, patterns, and whatnot.

I'd plan for a few days, but you might see results just in a solid morning of doing it. Don't know.

Of course, you probably don't have a few days. But -- how much time are you losing to this other stuff? Couldn't hurt. Beats giving people a book to read.

<comment><USER23> I find this both crazy and quite appealing! Maybe doing so after also dishing out some of the good books recommended elsewhere in the thread could work well. First read about good practice, then participate in it?

<comment><USER22> Yes. It struck me as one of those "crazy enough it might work" things.

Looking forward to trying it!

</comment></comment></comment><comment><USER24> My advice is that before you propose solutions, you ought to really figure out what the problem is. Is it ignorance, laziness, or something else? I've looked over the various responses and haven't seen one angle -- have you asked your team about why they are not doing what you'd like? There's a lot of advice about read this, do that, etc. but you don't yet know why they are not following what you think is common sense. You might find something surprising by putting it on the table, or at least you'll find the reasons they give. Then you can address those. My advice is to put this out as a question to your team and see how they react. You might even find out that some of the patterns you think are best are not, i.e., your team has a reason you didn't think of. For example, I created a 10-element array to speed the search of a big table in which all keys began with a digit from 0-9. The more experienced guy told me that in the .NET world, the convention was to use key-value pairs instead of an array. To satisfy him, I changed it to a hash table, where I hashed the first digit. It seemed pretty silly to me, making a hash table for what to me was clearly a better approach using a simple indexed array. He had in his mind the "right" way to do it, eventhough I still think the hashtable in this case was silly.

</comment><comment><USER25> If your timelines are such that you cannot institute a process for code reviewing pull requests and you have a team of developers, then I have to question the planning by the managers.

</comment><comment><USER26> I honestly think this complaint is poorly argumented. It depends on the nature of the project. When you say "findeventsfromthelast6hours" that's perfectly reasonable name for disposable code or private implementation. You should only be concerned about such name if it made it to the API somewhere. Hardcoding things is also not a bad thing by itself. If I had to guess, your team is under the impression the code they write is prototype and will be rewritten anyway, not API to be consumed by other parties or doesn't have a direction that allows them to make the proper abstractions. Sure you can demand nothing to be hardcoded, but you must remember eventually those params will have to come from somewhere. I see so many people move hardcoded values Java -> IOC/DB config or Erlang -> DB not realizing it's more difficult to reinitialize the component than to do a hot reload and speed up your development process at the very least. Whatever you do it must be for a well-defined reason. It's also possible your team developed their own process where it's easier or faster to fix these issues on the go rather than planning in advance.

<comment><USER27> Indeed, I think Robert Martin's "Clean Code" would agree that if you don't need to vary the "6 hours" part at run-time, then "findeventsfromthelast6hours" is actually better than passing in an "hours" argument ("Clean Code" advocates minimizing function arguments). Refactoring the name in the face of a one-time change in behavior (e.g. "4hours") should be trivial with any modern IDE.

</comment></comment><comment><USER28> Clean Code and The Pragmatic Programmer are both great books, but really your team needs to be doing code review on every line of code that is going to make it to production. It doesn't have to be /you/ reviewing all of it. As a bonus, having your team review each other's code builds more familiarity with the app(s) you are working on and allows all your team to learn from each other.

</comment><comment><USER29> Steve McConnell's _Code Complete_ might be a good resource. Could you buy a copy for each team member and take an hour each week to read and discuss a chapter? That might get you on the road to better coding practices.

[http://www.amazon.com/Code-Complete-Practical-Handbook- Const...](http://www.amazon.com/Code-Complete-Practical-Handbook- Construction/dp/0735619670)

</comment><comment><USER30> Each week, you take one of them to be your pair. Do pair programming for 2-3 hours each day of the week. Make a wiki page with code style guide and recommendations. Each common mistake you find your pair doing, add to the wiki page. At the end of the week, you and your pair review the commits you have done _and_ from a couple of others from the team.

</comment><comment><USER31> They are not coders. They are partners in success. Make sure first you treat them as such. Each person might have much to give above turning specs to code (ideas, processes, improvements, automations, design, architecture, etc...). If they feel they have a stake and their efforts are accommodated (and praised), there will naturally be an improvement.

<comment><USER32> Yes. This. The OP is NOT leading a team of programmers. He is asking HN to lead his team of programmers. "lead" is not a noun. It is a verb!

</comment></comment><comment><USER33> Sometimes it's more about learning clever architecture than clever, or better code. Clever architecture can often help keep your code an order of magnitude simpler.

The issue you may run into is seasoned developers are the ones who learn this over time.

Conversations based around "why" help a team understand the importance of:

\- creating a codebase that they will still want to / be able to work on without dealing with poor decisions of the past, o

\- being kind to your future self

\- realizing not everyone has had a relationship with a codebase for 3, 5, or even 10 years and what that might look like. In the real world, existing code bases are a reality. Optimizing for that reality, instead of the clean slate that university assignments, or startups provide can also be an important light bulb.

\- peer reviews, and teaching the why you do things a certain way are far more likely to get the lasting result you are seeking.

</comment><comment><USER34> Try having your team read these books:

[http://www.amazon.com/Writing-Solid-Code-Microsoft- Programmi...](http://www.amazon.com/Writing-Solid-Code-Microsoft- Programming/dp/1556155514)

[http://www.amazon.com/Practice-Programming-Addison-Wesley- Pr...](http://www.amazon.com/Practice-Programming-Addison-Wesley-Professional- Computing/dp/020161586X)

[http://www.amazon.com/Code-Complete-Practical-Handbook- Const...](http://www.amazon.com/Code-Complete-Practical-Handbook- Construction/dp/0735619670)

I know these are old books and are C and C++ oriented, but it helped me a lot during my formative years and helped me transition from being a decent programmer to being a decent engineer. They are short books which are well written and not very dense.

<comment><USER35> Code Complete has 960 pages, not in the short book category

</comment></comment><comment><USER36> To me, this is the difference between being a programmer and a software engineer. Software engineers think of the bigger picture and understand the overall impact of choices made in the code on other things. Programmers focus too much on just coding and don't see the bigger picture.

I am sure much of this has to do with experience and having had the opportunity to learn from good software engineering teams.

In my teams, I have handled this with mentorship. Recognize who in the team needs mentoring and assign them a code review buddy. If mentorship somehow doesn't work, you just have to manage those programmers and put them under tighter supervision. However, you can't expect much change until you set and communicate expectations. Be clear on what you expect and review against those benchmarks.

</comment><comment><USER6> What I've seen work is a combination of code reviews and ongoing continuing education.

\----- CODE REVIEW SIDE -----

This can include automated tools, human interaction, and computer-assisted human interaction. To start with, pick a set of command code standards and style guidelines. Google has nice ones for many languages that you can use as a starting point ([https://google- styleguide.googlecode.com/svn/trunk/](https://google- styleguide.googlecode.com/svn/trunk/)).

Secondly, enforce them through automated tools (e.g. in a Java shop, these might include PMD, FindBugs, Checkstyle, etc). Have everyone install the IDE plugins for those tools (along with your common config). Incorporate them into your continuous integration build process. Perhaps put in place a static analysis tool like Sonar to send regular reports on code issues.

The human element would start by having someone review committed code before it's allowed to be merged downstream. Git's pull requests, along with diff view systems like GitHub's, make this easy... but you can use workable practices with Subversion or whatever also.

There are limits to "pull request"-based code reviews, though. When change sets grow too large, it's difficult for the reviewer to understand the high- level vision for the changes. You start reviewing the trees, rather than the forest. So I think you still need periodic in-person code reviews, to walk through the state of a codebase at certain milestones and discuss higher-level issues.

\----- CONTINUING EDUCATION SIDE -----

The thing that I've seen work best here is a regular, ongoing lunch-and-learn type series. Take any of the standard code quality treatises (e.g. "Pragmatic Programmer", "Code Complete", "Clean Code", etc), and tackle a chapter per week. Better yet, split up the chapters and have the team members themselves present a chapter. It's great experience for them (if they're not TOO freaked out by public speaking), and you'll never learn something as deeply as you do through the process of teaching it to others.

The problem with lunch-n-learns is that you MUST have buy-in from management to make them a serious and ongoing part of your team culture. When deadlines are tight and there are fires to put out (and when are there not?), a lot of companies are quick to cancel that week's lunch-n-learn. When that happens, they lose traction and fall apart.

</comment><comment><USER37> Most tips here are very good, suggesting books ("Clean Code", etc.), team huddles and showing them the way. But you seem to be implying that they could be great coders - if they wanted to.

I can't help but feel like these programmers aren't very passionate about their code, and that's what you need to help them with. If they're naming variables wrong and hardcoding strings, but understand the asymptotic running times of what they're doing, I'd go on a hunch and say they're bored or unmotivated.

I say this because I recognize myself in some of these behaviors - when I want to get rid of something and don't care much about the project. "What's the fastest shortcut I could take to get me out of here?".

</comment><comment><USER38> Lots of good advice, but I suggest having the whole team review each others' code 100% of the time. In other words, each commit gets a random or rotating selection of two people who review the code.

Reviewing other people's code is almost as valuable as being reviewed. Even if it's not perfect all the time, it builds a good culture of coding and gives your developers valuable experience.

The culture of the code review should be a careful examination with Q&A. You need to take as long as you need to get it right. This is a great investment in your product and your team that will pay off starting right away and extending into the long term.

</comment><comment><USER39> It is your team, with your own culture, so I would not presume to tell you exactly how to do it, but I can give one general bit of advice:

Communicate.

Tell them what you are seeing, and just as importantly, why it can be a problem. Many times, beginner mistakes arise simply because they never have been exposed to the reasons for them being "mistakes" in the first place. So teach them. Nicely.

Think of them as students, and you are their teacher/mentor. Help them grow, support them and act as a resource so they can do their own jobs better. Treat the whole experience as an opportunity for growth, not a judgment on their skills.

</comment><comment><USER40> Below are a few things that could help but you said it yourself. If you don't have time to review then my guess is you are also pressuring the devs for time. Sometimes to make your deadlines they might have to cut corners. Maybe you can switch to a more agile process and instead of crazy deadlines you ask them what they can get done the next 2 weeks (correctly).

\- Setup process for them to review each others commits (Code Reviews)

\- Add a tool like FxCop, JsLint or JsHint to the build and commit process

\- Hire more senior programmers that they will look up too.

\- Paired programming

\- Be a team and do stuff as the team (We are not factory workers)

</comment><comment><USER41> Point them to some coding guidelines for the language/platform which you're developing.

For Clojure development: [https://github.com/bbatsov/clojure-style- guide](https://github.com/bbatsov/clojure-style-guide)

For Scala: [https://github.com/alexandru/scala-best- practices/](https://github.com/alexandru/scala-best-practices/) or [http://docs.scala-lang.org/style/](http://docs.scala-lang.org/style/)

</comment><comment><USER42> Technical books. Code videos from stuff like Google I/O and friends. Coding conventions. Peer programming. Use pull requests and assign them to another member of the team. It won't fix it overnight, but you'll notice the changes as they come in. Also, you might want to let them learn to write better code. People adapt best when you lead them, instead of getting them to do it. Everyone was a beginner and not everyone was exposed to the same amount of code or scenarios.

</comment><comment><USER43> I spent 10 years "coaching" (that word... blech...) teams, and from my experience there's no easy answers. What works for one team at one point in time might be horrible for other groups. Having said that, here are some things that have worked for me:

* If some of the people on the team have more skills than others, you could try asking people to pair program for part of the day. You could try setting up a lab space for this if people are interested.

* Weekly brown bag sessions where you talk about a technical topic of interest. Let people on the team nominate ideas. Do it over lunch and have the company have food delivered. The better the food, the more people will want to attend.

* You should get an automated build in place, and encourage people to do some level of automated testing if they aren't already. Some people take this a step further and use the automated tests to help drive out the design (Test-Driven Development by Kent Beck is a good book on this topic).

* You could try starting a technical book club where people read a chapter a week, and then get together and discuss it over lunch. Given your situation, I'd strongly recommend starting with "The Practice of Programming" by Kernighan and Pike. Again, it helps a lot to have the company get good food delivered.

Don't make a million changes at once. I might start with the book club if I were in your position. None of this stuff will magically transform your team, but these kinds of things can start creating a culture where people start to care more about the quality of their work. You'll encounter people who have very strong religious feelings for or against any one of the things I listed above, usually based on some past experience. I've seen each of the above succeed big and fail hard with different groups. Just try what seems to make the most sense for your team.

One last note: when you try things, don't do stuff in fits and starts - <USER2> with the team about what you're going to do, see if there's buy in, and if there is, commit to trying it for, say, four weeks. After the four week period is done, talk with the team about whether or not it's working for them, and if they'd like to stop or continue. Over time, you can add/remove/change more things in the same manner.

Good luck!

</comment><comment><USER44> Short term solution : Lead by example, a good chance that they can learn from those and maybe copy them afterward. But the code quality will improve. This can take your time but as long as you have several good examples, you can reuse those. Long term solution: Encourage them to watch conference and good books like Clean Code, or TDD books. Those are incredibly good. Maybe they are not interested in at first, and never, but those who want to be better will become ones.

</comment><comment><USER45> You absolutely need coding standards (the stricter, the better, as long as they make sense), especially with languages like C or Perl where you can shoot yourself in the foot with what looks like particularly "smart" coding.

I'd also recommend choosing a strict language with useful conventions like Go (www.golang.org) if you have the possibility to switch. If will prevent many (not all) headaches in the long run, even if it's not immediately obvious.

</comment><comment><USER46> If you can spend some money I recommend hiring someone good to give some lessons, some hours per week. Then there is also the option to give those lessons yourself.

<comment><USER47> This. The general form of this question is, "How do I help someone increase their skill level?"

If the topic were math, you'd immediately see that a tutor and a lot of practice were essential parts of the equation.

If the topic were baseball a coach and a lot of practice would leap instantly to mind.

However, it is too often the case that employers and managers draw a line between the "educational" period of a persons career and the "work" period of their career. They also draw a line between what is their responsibility (in terms of improving an employees skill set) and the individuals. Combined these two lines means it is easy to get into a situation where, as a manager or employers, you are likely to think "You should have learned this 'before'" or "You should learn this 'on your own time.'" Neither of which thoughts actually help get you closer to a more skilled employee.

</comment></comment><comment><USER48> 1\. Smaller commits. Break the project down into smaller tickets and have them check-in more frequently.

2\. Rotate who reviews so everyone gets a chance to review everyone and put yourself in the rotation.

3\. Lead by example. Write some code into production and submit yourself to review. Everyone writes code, everyone reviews, everyone gets reviewed.

4\. Each review find just one thing to refactor and let them know they should be looking for the same thing in other people's code.

</comment><comment><USER49> You can set up a weekly code review where you take turns letting each developer present a piece of code they wrote to the team, and then discuss and give feedback about that code.

Also direct them towards resources where they can learn clean code practices. Perhaps institute a monthly "book club" where you select books about good coding practices. I would suggest starting with Clean Code by Robert Martin

</comment><comment><USER50> I think you need to come up with a coding guideline. After that, you review/discuss it with your team.

Also, you may need to create a "checklist" and encourage your team to follow it as a way of self-check on their work.

In this way, you will be able to concentrate your reviews on important things (such as logic, etc) since the trivial errors were already eliminated.

</comment><comment><USER51> I've been in a technical lead position across 5 companies over the last 10 years, and after trying just about everything written or spoken about influencing team code quality, I finally found a formula that works:

1) Take on the most brutal coding tasks/features yourself. You will have to cherry-pick the upcoming work to look for things that just about any other engineer would freak out about if they got it assigned to them.

2) Knock it out of the park in terms of time-to-market __and __code quality. You need to do both, to eliminate the concern of, "We don't have time to write quality code." The code should be so clean, so well factored, so well unit tested, that you would be comfortable getting a code review from Martin Fowler, Kent Beck, and Bob Martin all at the same time. This also implies that you're read their books, and would know how to pass their code review.

3) Call a code review with the entire team, and aggressively code review your own code. There is always room for improvement in any code, depending on hour you interpreted current requirements and future needs. This has to include phrases like, "I didn't know what to do here so I…", "I really which I had more time to change this to…", "I went back-and-forth on how best to abstract this, but ultimately I chose this abstraction because." Basically, you're looking to show them the worst possible code review on the best possible code.

4) Depending on the personalities involved (including your own), decide how you are going to coach each engineer 1-on-1. No two people are alike, so you will need to dial your approach to each person. Some people will thing you are a show-off, some will think you intimidating, as well any another other human emotion and concern that causes someone to not seek out or not take advice. This is where your emotional IQ and communication skills will be tested.

5) When you start coaching them, don't go after every single flaw. Try to find the underlying root cause of the problem in the code, and address that. A common problem I run into is the people just don't understand OOP but think they do. I usually have to coach them on basics like encapsulation and cohesion, working them up to design patterns, and further up to domain modeling, all the while instructing on proper implementation technique (such as unit testing.) Once they have the fundamentals in place, you can begin fine-tuning certain implementation patterns.

6) Over time, at least one member of your team will get good. With their permission, publicly review their code. In this, you want to be very positive: "I like what they did here…", "That's a good way to encapsulate that problem", "That's a powerful abstraction, especially the way it's used…" This Rite of Passage should then become what other engineers are striving for, as only the best engineers are getting public praise fests.

This basic formula has served me very well with my current team, in that they are one-upping themselves on code-quality. Still, however, I take on the most grueling coding tasks to set the example and lead from the front. This acts to continue to demonstrate my commitment to code quality, as well and lets the team know I would not ask them to do something that I would not do myself.

</comment><comment><USER52> As for books, "Clean code" by Robert Martin is an obvious choice. It covers the fundamentals of good, clean code.

[http://www.barnesandnoble.com/w/clean-code-robert-c- martin/1...](http://www.barnesandnoble.com/w/clean-code-robert-c- martin/1101628669?ean=9780132350884&itm=1&usri=9780132350884)

</comment><comment><USER53> Depending on the language and context, an explicit method name like "findEventsFromLast6Hours" isn't that bad. If it's just a private helper method, I'd let it pass.

Empirically, I've found that methods with ambiguous parameters (e.g. "findEvents(6)") are a much bigger problem (event amongst senior programmers).

<comment><USER54> I also had a problem with this example from OP. It is generally a good idea to implement the minimum amount of functionality to satisfy the requirements. I have seen many complex systems fail because it was over-engineered with the idea that 'we might need this down the road'.

When requirements change, you almost always have to rewrite the code. If you don't have to rewrite the code, you still have to go back and read it to make sure it satisfies the requirements. Less code to deal with will make this process easier. There is no reason to over-engineer today for what might happen tomorrow.

Code for the here and now, and aggressively delete code whenever possible.

<comment><USER54> If your 'coders' are writing functions like findEventsFromLast6Hours, you are not giving them clear requirements.

I assume you gave this engineer the requirement 'find all events from the last 6 hours.'

You should have given them the requirement to find the latest events for a specified interval.

</comment></comment></comment><comment><USER55> I highly recommend (to everyone here for that matter) the book Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin. It deals specifically with the mistakes you've mentioned in your post, such as hardcoding and naming functions.

Great easy read. Cheers

</comment><comment><USER56> I would start with Refactoring by Martin Fowler. For me this is the quintessential book when it comes to basic software design principles. It introduces code smells and tells you step by step how and why to improve your code design

</comment><comment><USER57> If some gross code gets into the tree, nominate it for a code reading with a team of three or four people. This helps a lot because the code gets improved and the reviewers' styles also improve.

</comment><comment><USER58> Start by watching "The Downfall of Agile Hitler" [https://www.youtube.com/watch?v=l1wKO3rID9g](https://www.youtube.com/watch?v=l1wKO3rID9g)

</comment><comment><USER59> Forget all the craps about new silver bullet mantra (peer review, agile and peer coding and shit).

Just put them on mandatory level 2/3 support 20% of the time for the code that is written.

When you have to maintain code you fully grasp the concept of «well written code»: just code that is easy to maintain.

And every month try to have them talk about their top 3 reasons that makes them loose time when fixing code.

My fear with peer review is that it is very artificial, what I like with maintaining code is that you see your mistakes sometimes due to trying to write «clean» code.

Magic number deserves a bullet in the kneecap, but magic numbers disguised as factories are worse. A good code is a code where mistakes are obvious. Value these coders.

</comment><comment><USER57> Nominate crufty code for code readings. They are great to improve the quality of the code and that of the reviewers.

</comment><comment><USER60> do a half day workshop with your team going through typical mistakes, how to avoid them, and how to write good quality code - after that there should be no excuses.

pull requests also essential but it's still admin overhead for you to review everything

</comment><comment><USER61> PRs work. Pull requests serves to manage quality but also can find issues.

</comment><comment><USER32> the best way you can improve the quality of code is to LEAD BY EXAMPLE. you're not alone in that you've been given a leadership position in a circumstance outside your control, and it's naive to think that even if you were given your pick of the litter, that they'd all be A players who respect you and don't want your job, have issues with your quality, etc.

You absolutely cannot control people. The only way to get people to do things, and i mean the ONLY way is to get them to WANT to do it. Therefore, you have to ignore the people who aren't cooperating with you and focus on the one's who do. Treat them like gold and be willing to make compromises with your quality standards because they will not be the same as yours. Then, as you make inroads on the project together, the rest of the team members either have a choice to get on board or get left behind. It is that simple.

</comment><comment><USER62> Good coders should start new projects. Mediocre coders should maintain projects.

</comment><comment><USER63> I work at a place that requires code review and has automated checkers for "code quality". Let me tell you the obvious : the best code I see has these problems, because the best code is the best code because it uses the language to it's maximum effect, which often precludes having perfect "style". The best code is tested in functional ways, which means that it doesn't have "good coverage", nor does it really use unit tests more than a little bit.

And the worst code I see, by people who learned to code a month ago or worse and don't know any algorithms (but feel like they know better than people who've studied algorithms and languages for years) almost without exception perfectly styled. It contains moronic errors like swapping variables around (because these programmers do not know how to use the type system), it contains 5 unit tests for every single little function, because that increases the lines of code metric that is so universally used. And the reason for half the lines of good is "good practices".

Here's how you recognize good code : firstly it is not possible to shorten it without causing a MAJOR disaster in the readability area. Every concern is properly separated out into it's own pieces of code, and aside from the (short) main function there is very little single-purpose code. The typing system is used well. Prices and amounts are NOT the same data type, for example, and cannot be obviously switched. Unit tests exist for core algorithmic pieces only and other than that there are system tests that confront the code with real-world situations while running almost the entire program, ideally under heavy load with half the backend unresponsive, and has a statement that says the test fails if it takes longer than 1/10th of a second. It implicitly follows and beautifully implements a design document that is not written in word, but in a 10 to 15 line comment on top of the file/class.

Note the issues : 1) hardcoding things 2) naming mistakes

Both of the issues you complain about can be fixed mechanically or with absolutely minimal supervision through refactoring. Yet next to all the comments below suggest DOUBLING the manual effort needed to get code into the repository. While automated fixing might be problemating, writing linters that detect these problems is trivial.

Unless of course the problem is that you feel that you need to fix how others program because you "know better", but can't actually write code checkers. In this case, why are you leading them ?

So well in that case I'd advise a slice of humble pie, and a compilers course.

> I review commits now and then and find some of these issues - but due to the > nature and timeline of the project cannot do it for each and ever commit of > course.

You sound like someone with an MBA. A programmer would recognize this for what is is : a problem screaming to be automated. Code commits can be made dependant on code checkers succeeding - just write the ones you want/need. Can't do that ? You're not a programmer - or at least not a good one - <USER3> stop whining about how difficult programming is - learn it first.</comment>


The 188.8.131.52 resolver now supports DNS over Twitter - <AUTHOR> https://twitter.com/1111Resolver <comment><USER2> "I may have hit Twitter's API limit." .. Yeah, Twitter's a bit like that. It might work well on Telegram though :-)

</comment><comment><USER3> Given the number of people that still can't route to 18.104.22.168, this is an interesting backup!

<comment><USER4> Interested to see who that might be, it seems a bit nuts that that wouldn't work.

<comment><USER5> I mentioned this in the other thread yesterday, but my AT&T gigapower router is hard coded with 22.214.171.124 on an internal interface, so I can't use it. I can still use 184.108.40.206 though.

<comment><USER4> > _I mentioned this in the other thread yesterday, but my AT &T gigapower > router is hard coded with 126.96.36.199 on an internal interface_

Wow, AT&T of all people should know better. I mean, I understand the attraction to that address for customer setup reasons, and bypassing different configured NAT address ranges (i.e. 10/8, 172.16/12, and 192.168/16 networks), but surely a customer who configures a custom address range would be capable of finding the new address.

Here's hoping that as IPv6 becomes ubiquitous, this is replaced broadly with something standard, possibly based on ND.

<comment><USER6> And to help march towards ubiquity shouldn't we be encouraging IPv6-connected users to point to 2606:4700:4700::1111

Less junk traffic, less latency for folk behind CGNAT on IPv6-only mobile networks, no chance of collision with poorly a configured network equipment.

<comment><USER5> I switched to IPv6, and then back to v4. IPv6 just isn't ready for prime time yet. The random timeouts waiting for it to fall back to v4 when the v6 endpoint was down was annoying enough to get me to switch back.

I'll try it again in another year.

</comment></comment></comment></comment></comment></comment><comment><USER7> I assume this is as a joke?

<comment><USER8> Nope, its real. Slow but real. It makes a good backup DNS so you could use it to manually update your 'hosts' files.

<comment><USER7> I knew that it worked, I just assumed that it was made as a joke

Usually if I don't have dns access I don't have an easy way to access twitter I think? I could be wrong about this. Is this meant to be used by text messages?

<comment><USER9> Write a short script to resolve Twitter's address. Run it on a cron to pop it into your hosts file.

Now you can get to Twitter in the case of a resolver being down. Woo!

</comment></comment></comment></comment><comment><USER10> Is there any difference between which address you list first in your DNS list (220.127.116.11 and 22.214.171.124)? I saw a suggestion to list 18.104.22.168 first since it likely gets much less traffic.

<comment><USER11> I believe they point to the same network of servers, making it exactly the same. Having two IP addresses is just custom, and makes users resilient to address issues affecting one of the addresses.

It also might help APNIC establish how much of the traffic to 126.96.36.199 is due to Cloudflare running a popular public DNS service, vs. how much is due to the address by subtracting the 126.96.36.199 traffic from the 22.214.171.124 data.

</comment></comment><comment><USER12> Great! Now the whole world can see which domains you are interested in. This is supposed to be some last resort backup when all other DNS servers (220.127.116.11 and others) are down or blocked? In that extreme case of unavailability, what is the guarantee that local Govt is not involved and Twitter and/or sms to Twitter is not blocked.

Am I missing any use case here?

<comment><USER13> Perdy sure the twitter bot is a 'joke'.

Info on 18.104.22.168: [https://blog.cloudflare.com/announcing-1111/](https://blog.cloudflare.com/announcing-1111/)

</comment></comment><comment><USER8> How do you get a query to through?

<comment><USER14> Tweet to @1111Resolver followed by the DNS Record type and the Domain Name. Example: @1111Resolver A [http://google.com](http://google.com)

<comment><USER15> Not really familiar with twitter, but isn't tweeting directly to someone public? As in, everybody sees what you are trying to resolve?</comment></comment></comment>


What Is Abstract Algebra? [video] - <AUTHOR> https://www.youtube.com/watch?v=IP7nW_hKB7I&list=PLi01XoE8jYoi3SgnnGorR_XOW3IcK-TP6 <comment><USER2> If you are curious how does Abstract Algebra relate to software engineering, this book might be of your interest

[https://smile.amazon.com/Elements-Programming-Alexander- Step...](https://smile.amazon.com/Elements-Programming-Alexander- Stepanov/dp/032163537X)

The main selling point of this approach is that it can cut out a lot of code

In this talk, Sean Parent, at that time working on Adobe Photoshop, estimated that the PS codebase could be reduced from 3,000,000 LOC to 30,000 LOC (=100x!!) if they followed ideas from the book [https://www.youtube.com/watch?v=4moyKUHApq4&t=10s](https://www.youtube.com/watch?v=4moyKUHApq4&t=10s)

Another point of his is that the explosion of written code we are seeing isn't sustainable and that so much of this code is algorithms or data structures with overlapping functionalities. As the codebases grow, and these functionalities diverge even further, pulling the reigns in on the chaos becomes gradually impossible.

Bjarne Stroustrup (aka the C++ OG) gave this book five stars on Amazon (in what is his one and only Amazon product review lol).

[https://smile.amazon.com/review/R1MG7U1LR7FK6/](https://smile.amazon.com/review/R1MG7U1LR7FK6/)

<comment><USER3> _estimated that the PS codebase could be reduced from 3,000,000 LOC to 30,000 LOC (=100x!!)_

I challenge anyone making such claims to construct an even _moderately_ realistic example of where such reduction would be possible.

Here is a very simple and already very optimistic model that is still way below a 100x reduction: say my program consists nearly exclusively of sorting of various arrays and I write out bubble sort in full each time using for loops etc. rather than call a sort() procedure. Bubble sort takes roughly 20 lines of code to implement, so I would at best get a reduction of close to a 20x, rather than a 100x one.

<comment><USER4> I don't doubt that your conclusion is correct, but what if the sort is used in 10 other functions, each of which is used 10 times? If you inlined everything you would end up with 100 copies of bubble sort. The code blowup is exponential in the level of nesting.

<comment><USER2> Indeed. Another venue for why it cuts out code is that it makes code more reusable. As a result, you are more likely to integrate nicely with already written libraries than write your own code. Technically, this is a way of reducing your codebase as well lol.

</comment></comment></comment></comment><comment><USER5> Here are fantastic Algebra lectures (Abstract Algebra, Fall 2003, Harvard) by my favorite lecturer Benedict Gross: [https://www.youtube.com/playlist?list=PLelIK3uylPMGzHBuR3hLM...](https://www.youtube.com/playlist?list=PLelIK3uylPMGzHBuR3hLMHrYfMqWWsmx5)

<comment><USER6> There's a link on the sidebar of Gross's page [1] to an old version of the course site; this lets you download video, audio, notes, and homework. Even if you know everything in Artin's book the lectures are rarely boring.

[1] [http://www.math.harvard.edu/~gross/](http://www.math.harvard.edu/~gross/)

<comment><USER7> Do you mean Michael Artin's Algebra? Just took his Algebra I (18.701) at MIT last semester. An incredibly challenging class, but he's a really excellent lecturer and a very likeable guy. Still really sharp.

<comment><USER6> Yes, thanks -- I should have made clear that this is what Gross used. Wonderful book.

</comment></comment></comment></comment><comment><AUTHOR> Also see the "Modern Algebra - Visual Group Theory" online course and video lectures by Prof Matthew Macaule at Clemson:

Course material, videos, and slides: [http://www.math.clemson.edu/~macaule/classes/m16_math4120/in...](http://www.math.clemson.edu/~macaule/classes/m16_math4120/index.html)

YouTube Playlist: [https://www.youtube.com/watch?v=UwTQdOop- nU&list=PLCc9vhgj7w...](https://www.youtube.com/watch?v=UwTQdOop- nU&list=PLCc9vhgj7wo7ghkzJCUaeAw1ceB1BOaXG)

</comment><comment><USER8> This was previously posted slightly over a year ago and had some good discussion - [https://news.ycombinator.com/item?id=10686610](https://news.ycombinator.com/item?id=10686610)

</comment><comment><USER9> The common trend in educational videos is very interesting. The videos that are made approximately from 2-10 minute long with animation and pictures are very easy to follow than to watch hour long stanford or mit live class room recordings.

<comment><USER10> Often, though, hour long lectures is the only way to go. You just can't learn much in 10 minutes with an animated video. Sometimes you just got to delve in.

<comment><USER11> I think watching something like this before watching a deep dive or reading a text book could be useful, just to give you kind of a lay of the land and some intuition.

</comment></comment></comment><comment><USER12> Évariste Galois, a major contributor to abstract algebra, had an interesting life. He had participated in the French Revolution of 1830; worked on mathematics while in jail; and died when he was 20 years old as a result of being shot in the abdomen in a duel.

[https://www.youtube.com/watch?v=pdYe4BKcm74](https://www.youtube.com/watch?v=pdYe4BKcm74) (Galois Theory - Math History)

[https://en.wikipedia.org/wiki/%C3%89variste_Galois](https://en.wikipedia.org/wiki/%C3%89variste_Galois)

</comment><comment><USER13> Great explainer. Though I'm still not sure what the relation is between abstract algebra and regular algebra, other than the application of higher dimensional equations.

<comment> number-sequence Abstract algebra is often about studying structure on sets. That usually takes the form of studying operator(s) with certain properties and the elements that they work with. Some early examples that students see are things like rotations/reflections of n-gons, modular arithmetic, polynomials, matrix spaces, and fields.

It is different from regular algebra in the sense that often one starts with a set and operation one supposes to have a particular kind of property (perhaps it's a group, or perhaps it's a field, or perhaps it's a certain kind of field (maybe separable, or local, or ...)). Then from these assumptions one proves facts about the assumed algebraic structure.

It's different in that often particular elements aren't of much interest, and it's not as tied down to a particular context.</comment></comment>