It's lame.

By the end of reading the chapter, reader should have a solid understanding of basic Go syntax and be able to read-n-understand trivial sources written in Go. It should not also be locked on Go only, I should be generic as much as possible.

Currently, the book doesn't have a solid contents plan, but some occasional pages aligned in some weird way. The plan draft on Google Docs must get expanded in order to cover all the data that we are gonna eventually publish.

Generally, book must be separated into 3-4 logical sections, such as Think!, Steady! or Hack!.

Beginners usually focus on programming languages a lot and miss the whole point of paradigms and software engineering approach. I should carefully describe everything from ASM to FP and outline all the major pros/cons and general differences.

I should also somehow address code quality and overengineering issues. Easy to read and commented code listings might be good as well.

General engineering approach described in Think! now is bloody rubbish. This issue is all about redesigning it. Here is the main schema:

1. Problem (create/fix what? for whom?)
2. Research (existing solutions, libraries, related discussions?
3. Analysis (categorizing all the data mined during research)
4. Implementation (looking for the most efficient ways of actual coding)

Some key points I might want to play with:

• You should never work on ambiguous, hazy, imprecise problems or problems from subject area you are not familiar with;
• While doing a research, try to mine as much data as possible, focus on existing solutions and alternatives and their pros/cons first;
• While analysing research data, carefully estimate your central values and build corresponding priorities, focus on these, so you could outline data that actually matters;
• Before doing actual coding, make sure you've got a schedule (implementation stages — PoC, MVP, Alpha, Beta, etc) and some sort of a plan that you'd stick to during the whole development cycle.

OOP is such a buzzword, all the newcomers know some shit about it. Crucial task here is to get all the rubbish out of the reader's head and build a solid understanding the aims/values/priorities of OOP.

This issue should be closed only when all the chapters from Steady! are consistent. I should not start this inb4 all the chapters are ready. The whole goal of this issue is to fix most misprints, articles, stylistic mistakes, add some links to resources, maybe jokes.

Both Start! and Think! sections introduced a bunch of terms that reader mightn't know, links for comprehensive resources missing. Wikipedia would be fine, though.

This chapter should provide essential knowledge to basic terms, such as Software, Hardware, Language, Compiler, etc. It's really important to draw a coherent picture for a reader. A short list of things I should focus on:

• History of CS and computer architectureww
• BIOS
• Memory, memory management
• Different operation systems
• "Programming Language is how compiler understands algorithms and translates them into assembly"