Found 23 comments on HN
charlysl · 2018-11-17 · Original thread
"On the criteria to be used in decomposing systems into modules" (1972) - because the core principles of modularity haven't changed [https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria...]

"The Mythical Man Month" (1975) - because human nature hasn't changed [https://www.amazon.com/Mythical-Man-Month-Software-Engineeri...]

"The History of Fortran I, II, and III" (1979) - because this historical piece by the author of the first high level language brings home the core principles of language design [https://archive.org/details/history-of-fortran]

"The Unix Programming Environment" (1984) - because the core basics of the command line haven't changed [https://www.amazon.com/Unix-Programming-Environment-Prentice...]

"Reflections on Trusting Trust" (1984) - because the basic concepts of software security haven't changed [https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...]

"The Rise of Worse is Better" (1991) - because many of the tradeoffs to be made when designing systems haven't changed [https://www.jwz.org/doc/worse-is-better.html]

"The Art of Doing Science and Engineering: Learning to learn" (1996) - because the core principles that drive innovation haven't changed [https://www.youtube.com/playlist?list=PL2FF649D0C4407B30] [https://www.amazon.com/Art-Doing-Science-Engineering-Learnin...]

"xv6" (an x86 version of Lion's Commentary, 1996) - because core OS concepts haven't changed [https://pdos.csail.mit.edu/6.828/2011/xv6/xv6-rev6.pdf] [https://pdos.csail.mit.edu/6.828/2014/xv6/book-rev8.pdf]

jmcomets · 2017-09-12 · Original thread
I recommend reading The Mythical Man Month[1] to anyone interested in proper SWE project management. There are so many wannabe managers out there that will just through more people at a project which is slowing down.

To quote the book: "Adding manpower to a late software project, makes it later". There's some really good stuff in there, even for those of us that are less interested in management.

[1]: https://www.amazon.com/Mythical-Man-Month-Software-Engineeri...

W0lf · 2017-06-05 · Original thread
I've gathered all the book titles in this thread and created Amazon affiliate links (if you don't mind. Otherwise you still have all the titles together :-) )

A Pattern Language, Alexander and Ishikawa and Silverstein http://amzn.to/2s9aSSc

Advanced Programming in the Unix Environment , Stevens http://amzn.to/2qPOMjN

Algorithmics: the Spirit of Computing, Harel http://amzn.to/2rW5FNS

Applied Crytography, Wiley http://amzn.to/2rsULxS

Clean Code, Martin http://amzn.to/2sIOWtQ

Clean Coder, Martin http://amzn.to/2rWgbEP

Code Complete, McConnel http://amzn.to/2qSUIwE

Code: The Hidden Language of Computer Hardware and Software, Petzold http://amzn.to/2rWfR9d

Coders at Work, Seibel http://amzn.to/2qPCasZ

Compilers: Principles, Techniques, & Tools, Aho http://amzn.to/2rCSUVA

Computer Systems: A Programmer's Perspective, O'Hallaron and Bryant http://amzn.to/2qPY5jH

Data Flow Analysis: Theory and Practice, Khedker http://amzn.to/2qTnSvr

Dependency Injection in .NET, Seemann http://amzn.to/2rCz0tV

Domain Driven Design, Evans http://amzn.to/2sIGM4N

Fundamentals of Wireless Communication, Tse and Viswanath http://amzn.to/2rCTmTM

Genetic Programming: An Intrduction, Banzhaf http://amzn.to/2s9sdut

Head First Design Patterns, O'Reilly http://amzn.to/2rCISUB

Implementing Domain-Driven Design, Vernon http://amzn.to/2qQ2G5u

Intrduction to Algorithms, CLRS http://amzn.to/2qXmSBU

Introduction to General Systems Thinking, Weinberg http://amzn.to/2qTuGJw

Joy of Clojure, Fogus and Houser http://amzn.to/2qPL4qr

Let over Lambda, Hoyte http://amzn.to/2rWljcp

Operating Systems: Design and Implementation, Tanenbaum http://amzn.to/2rKudsw

Parsing Techniques, Grune and Jacobs http://amzn.to/2rKNXfn

Peopleware: Productive Projects and Teams, DeMarco and Lister http://amzn.to/2qTu86F

Programming Pearls, Bentley http://amzn.to/2sIRPe9

Software Process Design: Out of the Tar Pit, McGraw-Hill http://amzn.to/2rVX0v0

Software Runaways, Glass http://amzn.to/2qT2mHn

Sorting and Searching, Knuth http://amzn.to/2qQ4NWQ

Structure and Interpretation of Computer Programs, Abelson and Sussman http://amzn.to/2qTflsk

The Art of Unit Testing, Manning http://amzn.to/2rsERDu

The Art of Unix Programming, ESR http://amzn.to/2sIAXUZ

The Design of Design: Essays from a Computer Scientist, Brooks http://amzn.to/2rsPjev

The Effective Engineer, Lau http://amzn.to/2s9fY0X

The Elements of Style, Strunk and White http://amzn.to/2svB3Qz

The Healthy Programmer, Kutner http://amzn.to/2qQ2MtQ

The Linux Programming Interface, Kerrisk http://amzn.to/2rsF8Xi

The Mythical Man-Month, Brooks http://amzn.to/2rt0dAR

The Practice of Programming, Kernighan and Pike http://amzn.to/2qTje0C

The Pragmatic Programmer, Hunt and Thomas http://amzn.to/2s9dlvS

The Psychology of Computer Programming, Weinberg http://amzn.to/2rsPypy

Transaction Processing: Concepts and Techniques, Gray and Reuter http://amzn.to/

Types and Programming Languages, Pierce http://amzn.to/2qT2d6G

Understanding MySQL Internals, Pachev http://amzn.to/2svXuFo

Working Effectively with Legacy Code, Feathers http://amzn.to/2sIr09R

Zen of graphics programming, Abrash http://amzn.to/2rKIW6Q

Jtsummers · 2016-12-14 · Original thread
Mythical Man-Month, Fred Brooks [0]. Very informative series of essays on his experiences and lessons learned with IBM. If nothing else, helps to properly frame my expectations on projects with respect to resources needed to properly coordinate with others, and the pros and cons of adding people to projects at different stages (and in different roles).

Getting Things Done, David Allen [1]. Useful toolkit for getting things out of my head and onto paper (or org-mode or OmniFocus) so that I can properly focus and prioritize my time on the things I need to get done.

Communicating Sequential Processes, C.A.R. Hoare [2]. Strongly influenced the way I think about programs in general, but specifically in the embedded field where I work. (NB: I've not actually read or worked through the full text, but mainly taken what was needed to properly communicate ideas in my designs or to analyze designs and systems others have produced. This is a task for myself for early next year.)

Moonwalking with Einstein, Joshua Foer [3]. I've always had a good memory, I actually picked this up to give to a girlfriend who had a terrible memory and read it in a couple days before giving it to her (she was out of town when it arrived). Helped to explain methods that I'd somehow developed over the years, and gave me concepts and a better understanding of other methods of memory acquisition (for either short or long term purposes). If you really want to improve your memory, there are probably better resources to learn specific techniques, but this was an informative and entertaining overview. WRT work, we have to keep large systems in our minds all the time, and potentially dozens of different systems written in different languages. Memory is critical for this, even if it's just the memory of where to find the information and not the information itself.

Fluent Forever, Gabriel Wyner [4]. This one is my current read. Goes back to Moonwalking with Einstein. While the book is itself about language acquisition, it's actually given me quite a bit to think about with respect to general learning and memory acquisition (in this case, specifically for long term retention and recall). We have a couple training programs (we need more) for our new hires on development and testing. There are some concepts in here and in related readings that I think would greatly improve how we teach these folks what they need to know and in a way that would improve their retention of that information. We have a lot of people retiring in the next 1-3 years, so this is actually quite critical right now, though management is quite lackadaisical about it.

[0] https://www.amazon.com/Mythical-Man-Month-Software-Engineeri...

[1] https://www.amazon.com/Getting-Things-Done-Stress-Free-Produ...

[2] http://usingcsp.com/cspbook.pdf

[3] https://www.amazon.com/Moonwalking-Einstein-Science-Remember...

[4] https://www.amazon.com/Fluent-Forever-Learn-Language-Forget/...

=========================================

EDITS:

The Toyota Way, Jeffrey Liker [5]. I grokked Lean from this. Hardware focused, but the concepts can be (and have been) generalized to other process focused fields. This has helped with understanding what business processes really need to be codified, what feedback mechanisms need to be present for improvement, the criticality of bottom-up feedback and improvement (employee investment in the company/product cannot be overvalued if you want quality and good craftsmanship).

The Little Schemer, Friedman & Felleisen [6]. Going back to the comments on Fluent Forever. The structure of this is fantastic for conveying and helping students retain information. The Socratic method is very useful, and structuring courses and introductory material in this format is useful, this happened to be my introduction to it (well, I'd heard it before, but my first time really encountering it in practice). It's a useful tool for solo-study of a topic (pose your own questions and construct answers), and as a method of guiding someone to a conclusion or better understanding. Also useful in debugging software or decoding software you didn't write, after a fashion.

[5] https://www.amazon.com/Toyota-Way-Management-Principles-Manu...

[6] https://mitpress.mit.edu/books/little-schemer

angersock · 2016-10-31 · Original thread
Or The Mythical Man Month ( https://www.amazon.com/Mythical-Man-Month-Software-Engineeri... )

Honestly I'm kinda surprised that didn't come up sooner...but only half-surprised.

GFischer · 2016-03-16 · Original thread
I second that observation. I wish the manager at my day job read ANYTHING, at the very least some informercial-laden industry publication.

In my case, I'd like him to read Fred Brooks' "The Mythical Man-Month", to make him understand how a programming system costs a lot more than a simple module.

Summary: http://javatroopers.com/Mythical_Man_Month.html

In second place, I'd place "Peopleware", so he'd understand the importance of communications, and how the current office arrangement is losing the company a lot of money:

Summary: http://javatroopers.com/Peopleware.html

Amazon link to both:

http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...

http://www.amazon.com/Peopleware-Productive-Projects-Second-...

I think reading this book[1] is even more important than learning to use a keyboard (and mouse) with the intention of creating software or any complex system.

Knowing your limits is one thing, but understanding why/how they are being manipulated by outside forces (e.g. overestimating ability) is another. And how to counter those forces is also included in these pages.

Thank's for the sanity and well-managed project advice Fred!

[1] http://www.amazon.com/Mythical-Man-Month-Software-Engineerin...

Joe Armstrong's paper on the history of Erlang (of which he was one of the authors) is superb (though it's less about corporate culture than about the language): http://cobweb.cs.uga.edu/~maria/classes/4500-Spring-2010/pap...

There's The Mythical Man-Month: http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...

Showstopper, the book about the development of Windows NT, is great: http://www.amazon.com/Show-Stopper-Breakneck-Generation-Micr...

A little surprised to see that the Mythical Man Month isn't on that list: http://amzn.to/1ZHWUlF
scholia · 2015-12-15 · Original thread
Indeed, the history of the development of very large software systems has been littered with disasters. Don't people read The Mythical Man-Month any more?

http://www.amazon.com/Mythical-Man-Month-Software-Engineerin...

I'm a huge believer in going back to primary texts, and understanding where ideas came from. If you've liked a book, read the books it references (repeat). I also feel like book recommendations often oversample recent writings, which are probably great, but it's easy to forget about the generations of books that have come before that may be just as relevant today (The Mythical Man Month is a ready example). I approach the reading I do for fun the same way, Google a list of "classics" and check for things I haven't read.

My go to recommendations:

http://www.amazon.com/Structure-Scientific-Revolutions-50th-... - The Structure of Scientific Revolutions, Thomas Kuhn, (1996)

http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master... - The Pragmatic Programmer, Andrew Hunt and David Thomas (1999)

Things I've liked in the last 6 months:

http://www.amazon.com/How-Measure-Anything-Intangibles-Busin... - How to Measure Anything, Douglas Hubbard (2007)

http://www.amazon.com/Mythical-Man-Month-Software-Engineerin... - Mythical Man Month: Essays in Software Engineering, Frederick Brooks Jr. (1975, but get the 1995 version)

http://www.amazon.com/Good-Great-Some-Companies-Others/dp/00... - Good To Great, Jim Collins (2001)

Next on my reading list (and I'm really excited about it):

http://www.amazon.com/Best-Interface-No-brilliant-technology... - The Best Interface is No Interface, Golden Krishna (2015)

If you're interested in this topic, might I recommend:

No Silver Bullet: Essence and Accidents of Software Engineering, Frederick Brooks (1987) - http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBulle...

No Silver Bullet Refired, Frederick Brooks (1995)

Both can be found (along with lots of other good ideas) in The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition - http://www.amazon.com/Mythical-Man-Month-Software-Engineerin...

Fred Brooks, author of No Silver Bullet[0] which GP is referring to, and the fairly famous Mythical Man Month[1].

[0] http://faculty.salisbury.edu/~xswang/Research/Papers/SERelat...

[1] http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...

eob · 2014-01-20 · Original thread
You might be interested in this book. It's required reading in many CS curricula:

http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...

hga · 2013-10-23 · Original thread
Note: in the 20th anniversary 2nd edition of The Mythical Man Month (http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...), in one of the new chapters, Brook's backs off of his original "Build one to throw away" advice.
hga · 2013-08-30 · Original thread
It's been a long time since I've read either, but I can state in general that software engineering concepts don't tend to get outdated. The state of the art stuff I learned in the late 1970's is still almost entirely valid, although when it comes to low level stuff you'd want to e.g. adopt the advice about goto statements to other non-local things we are confronted with nowadays.

So reading an old classic like The Mythical Man Month isn't going to be a waste of time at all and is strongly recommended, but later really good stuff like these two books have additional lessons we've learned since then. So read the 20th anniversary version of that book (http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...), in which the author revisits issues and e.g. modifies his advice to "plan to throw one (version) away, because you will". The potential state of the art has gotten better, you can often get away with not doing that.

sjclemmy · 2013-01-04 · Original thread
I did the same; taught myself css, php, javascript and quit my FTJ last Christmas. Best thing I ever did.

I also sent the following as advice to someone wanting to get into web dev:

"I was just thinking of 'easy ins' to the world of web development and a good source of information is http://news.ycombinator.com/ there's a lot of information from people who work in the world of tech startups and it's good information.

Also - if you are wanting to do php dev the key things to learn are: Software engineering techniques and practice - object oriented development and abstract patterns are key to how to think about good development. Database design and development (1st normal form, third normal form etc) Learn SQL. (SQL for dummies or similar is good for the basic commands and syntax etc.) Stackoverflow.com - it's the best source of help for software development on the internet. read books, the ones that come up again and again when people talk about learning to program:

http://www.amazon.co.uk/Code-Complete-Practical-Handbook-Con... http://www.amazon.co.uk/Mythical-Month-Essays-Software-Engin... http://www.amazon.co.uk/The-Pragmatic-Programmer-Andrew-Hunt...

also - look at github.com - that's where programmers keep their source code.

Learn about Object Oriented Programming, Design Patterns, MVC (which is a design pattern) is specifcally useful for web development.

Also - demand for javascript programmers will increase over the coming years because of things like jQuery and Ajax.

That's my starter for ten - if you are interested in a career as a web programmer.

If you want to focus more on the html/css design side you could do worse than focusing on one CMS - such as wordpress and learning it inside out - you could then offer that to clients and it's a good way to provide web sites cheaply with very little effort."

robomartin · 2012-11-27 · Original thread
OK, if you don't have any real experience in low-level embedded coding (relevant to device drivers), RTOS or OS design in general, file systems, data structures, algorithms, interfaces, etc. And, if you have "hobby level" experience with Assembler, C and C++. And, if your intent is to write a desktop OS, from the ground up, without making use of existing technologies, drivers, file systems, memory management, POSIX, etc. Here's a list of books that could be considered required reading before you can really start to write specifications and code. Pick twenty of these and that might be a good start.

In no particular order:

1- http://www.amazon.com/C-Programming-Language-2nd-Edition/dp/...

2- http://www.amazon.com/The-Answer-Book-Solutions-Programming/...

3- http://www.amazon.com/The-Standard-Library-P-J-Plauger/dp/01...

4- http://www.amazon.com/C-Traps-Pitfalls-Andrew-Koenig/dp/0201...

5- http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp...

6- http://www.amazon.com/Data-Structures-In-Noel-Kalicharan/dp/...

7- http://www.amazon.com/Data-Structures-Using-Aaron-Tenenbaum/...

8- http://www.amazon.com/Mastering-Algorithms-C-Kyle-Loudon/dp/...

9- http://www.amazon.com/Code-Complete-Practical-Handbook-Const...

10- http://www.amazon.com/Design-Patterns-Elements-Reusable-Obje...

11- http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...

12- http://www.amazon.com/The-Programming-Language-4th-Edition/d...

13- http://www.amazon.com/The-Standard-Library-Tutorial-Referenc...

14- http://www.amazon.com/API-Design-C-Martin-Reddy/dp/012385003...

15- http://www.amazon.com/The-Linux-Programming-Interface-Handbo...

16- http://www.amazon.com/Computer-Systems-Programmers-Perspecti...

17- http://www.amazon.com/System-Programming-Unix-Adam-Hoover/dp...

18- http://www.amazon.com/Memory-Programming-Concept-Frantisek-F...

19- http://www.amazon.com/Memory-Management-Implementations-Prog...

20- http://www.amazon.com/UNIX-Filesystems-Evolution-Design-Impl...

21- http://www.amazon.com/PCI-System-Architecture-4th-Edition/dp...

22- http://www.amazon.com/Universal-Serial-System-Architecture-E...

23- http://www.amazon.com/Introduction-PCI-Express-Hardware-Deve...

24- http://www.amazon.com/Serial-Storage-Architecture-Applicatio...

25- http://www.amazon.com/SATA-Storage-Technology-Serial-ATA/dp/...

26- http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Inte...

27- http://www.amazon.com/Professional-Assembly-Language-Program...

28- http://www.amazon.com/Linux-Kernel-Development-3rd-Edition/d...

29- http://www.amazon.com/Version-Control-Git-collaborative-deve...

30- http://www.amazon.com/Embedded-Software-Primer-David-Simon/d...

31- http://www.amazon.com/Programming-Embedded-Systems-C/dp/1565...

32- http://www.amazon.com/Making-Embedded-Systems-Patterns-Softw...

33- http://www.amazon.com/Operating-System-Concepts-Abraham-Silb...

34- http://www.amazon.com/Performance-Preemptive-Multitasking-Mi...

35- http://www.amazon.com/Design-Operating-System-Prentice-Hall-...

36- http://www.amazon.com/Unix-Network-Programming-Sockets-Netwo...

37- http://www.amazon.com/TCP-Illustrated-Volume-Addison-Wesley-...

38- http://www.amazon.com/TCP-IP-Illustrated-Vol-Implementation/...

39- http://www.amazon.com/TCP-Illustrated-Vol-Transactions-Proto...

40- http://www.amazon.com/User-Interface-Design-Programmers-Spol...

41- http://www.amazon.com/Designing-Interfaces-Jenifer-Tidwell/d...

42- http://www.amazon.com/Designing-Interfaces-Jenifer-Tidwell/d...

43- http://www.amazon.com/Programming-POSIX-Threads-David-Butenh...

44- http://www.intel.com/p/en_US/embedded/hwsw/software/hd-gma#d...

45- http://www.intel.com/content/www/us/en/processors/architectu...

46- http://www.intel.com/p/en_US/embedded/hwsw/hardware/core-b75...

47- http://www.hdmi.org/index.aspx

48- http://en.wikipedia.org/wiki/Digital_Visual_Interface

49- http://www.amazon.com/Essential-Device-Drivers-Sreekrishnan-...

50- http://www.amazon.com/Making-Embedded-Systems-Patterns-Softw...

51- http://www.amazon.com/Python-Programming-Introduction-Comput...

52- http://www.amazon.com/Practical-System-Design-Dominic-Giampa...

53- http://www.amazon.com/File-Systems-Structures-Thomas-Harbron...

54- ...well, I'll stop here.

Of course, the equivalent knowledge can be obtained by trial-and-error, which would take longer and might result in costly errors and imperfect design. The greater danger here is that a sole developer, without the feedback and interaction of even a small group of capable and experienced programmers could simply burn a lot of time repeating the mistakes made by those who have already trenched that territory.

If the goal is to write a small RTOS on a small but nicely-featured microcontroller, then the C books and the uC/OS book might be a good shove in the right direction. Things start getting complicated if you need to write such things as a full USB stack, PCIe subsystem, graphics drivers, etc.

kenkyhuang · 2011-01-21 · Original thread
The Mythical Man Month, although old, has some great tips for estimating software engineering work.

http://www.amazon.com/Mythical-Man-Month-Software-Engineerin...

tokenadult · 2010-11-27 · Original thread
Does The Mythical Man Month by Brooks

http://www.amazon.com/Mythical-Man-Month-Software-Engineerin...

qualify as a programming book for this thread (maybe not)? It has no information on how to write "Hello, World" in any language, and little how-to information about coding, but a lot of information about effective programming, and it is a very interesting, readable book.

AmitinLA · 2010-08-20 · Original thread
I come from a similar situation and faced similar challenges, especially after trying to launch a web startup with no financing and no developers on board. It failed. I'm determined to stay in tech, so here's some of my (occasionally conflicting) thoughts.

1) You call yourself a business guy, but are you a product guy? If you're a product guy -- if you can understand the soul of a product and how it interacts with people -- that can be inherently valuable. In my experience, most people I've met may be "tech" or "business", but they're not product people.

2) Get an internship. Beg. Show up, prove why you're valuable, send unsolicited resumes with advice and biz dev/product suggestions. Be humble, but not too much. Work for free for a couple months, or at minimum wage or whatever is legal. Just get your foot in the door.

3) Read. The Elements of User Experience (http://amzn.to/aFNjSn), The Mythical Man Month (http://amzn.to/cFLDlB) -- these are just to get you started. Learning to code a little bit will be good as well. The point is not to become an expert developer, but to learn how developers think. Think of your reading as travel literature and learn about different cultures.

4) Look for non-sexy opportunities. Twitter, FB, 4SQ, Zynga etc., get all the hype, but there's tons of need for software development and product design in what I call the "iceberg industries." The trucking industry brings in $250 billion dollars in revenue every year. That's almost twice the size of the airline industry and yet a typical website of theirs looks like this: http://www.highwayfreight.com/index.php

5) Think about CPG (even though it's not tech, it still can be a startup). It's a risky, tough move and faces lots of market forces, but can be incredibly lucrative. You could find a small local product that you believe in, invest some cash to get equity, and try to make them big. As a consultant, your skills may be valuable because the problems in these types of entrepreneurial efforts are operational problems, not innovation problems.

6) Don't worry too much about the idea or where you're working right now: your goal is to build professional and personal credibility. Give away your great ideas. Most people who have them don't tend to have just one.

7) Don't worry about home runs. Most entrepreneurs I know have small lifestyle businesses and love their companies no matter the size. It's kinda like having a kid. S/he's probably not going to grow up to be president, but you're going to love 'em anyway.

Maro · 2010-06-25 · Original thread
By Fred Brooks, author of The Mythical Man-Month. I'm reading the book right now, it's great.

Here's a link to MMM in case someone hasn't read it:

http://www.amazon.com/Mythical-Man-Month-Software-Engineerin...

10ren · 2010-06-20 · Original thread
See p. 7 of Brooks' The Mythical Man-Month, for "The Joys of the Craft" http://www.amazon.com/Mythical-Man-Month-Software-Engineerin...

He lists 5: creation; usefulness; intricacy; constant novelty; tractability.

Some of these are in common with graphic design; but the "constant novelty" perhaps addresses your "boredom". Turing said that programming need never become boring, because any repetitive coding (or concept) can be captured in a function or module. Once you're worked out the solution to a problem, you write a reusable module to deal with that problem, and embodies your understanding of it, and you don't have to do it again. So it's always new problems.

Now, in practice, it isn't always that easy. Code that can be reused generally is much harder to write than code for one specific case (the literal meaning of ad hoc: "for this"). The hardest part is specifying what it do, not coding how. This approaches AI: to go from a problem that initially you cannot even understand, to one that you can automate 100%, is transcendent. Almost Frankensteinian... (aka The Modern Prometheus).

For me personally: I get a simple pleasure from making something happen on the screen (like any act of creation); but I actually don't like programming much for its own sake. I enjoy solving problems, and making them real. It's easy to dream something; but to do it is a real accomplishment. And anything on the road of that journey becomes equally important.

I don't know what stage you're at, but it's possible that you're not yet up to wrapping up the common parts of your coding, so you don't have to do them again. If you keep on typing the same predictable, mechanical things, that would be boring. Computers are ideal for this kind of mechanical work.

Get dozens of book recommendations delivered straight to your inbox every Thursday.