About Me

Krzysztof Kula #

I use also: krzychukula and Kris Kula

my image

See my CV

I like reading books and to remember more from each one of them I write reviews.
On a daily basis, I solve problems with code (sometimes by deleting code).

I highly value work-life separation and I actively try to be unavailabe after work.

This page and the whole blog is work in progress so let me know by writing to kris at the email domain of this blog if you have any feedback.

Click here if you want to see my old blog

Organizer or Former Organizer #

Participant #

Courses #

Projects (with public links) #

Personal Projects #

Quotes #

"Self-education is, I firmy believe the only kind of education there is”
― Isaac Asimov

"Call it lying if you like; but if you prefer to not play the game and to always be honest and upfront, to not complain when others call you obnoxious and arrogant.”
― The 48 Laws of Power by Robert Greene; Joost Elffers

Duty Calls

“Don’t complain; just work harder.”
― Randy Pausch

“Installing software is like a first date: if it can't be polite, smart, and generous, what should I expect later?”
― Scott Berkun

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.”
― Bjarne Stroustrup

“If you are neutral in situations of injustice, you have chosen the side of the oppressor. If an elephant has its foot on the tail of a mouse and you say that you are neutral, the mouse will not appreciate your neutrality.”
— Desmond Tutu

“Be conservative in what you do, be liberal in what you accept from others (often reworded as "Be conservative in what you send, be liberal in what you accept”
— Jon Postel

“Learning about "for" loops is not learning to program, any more than learning about pencils is learning to draw.”
— Bret Victor

"Don't ignore your dreams; don't work too much; say what you think; cultivate friendships; be happy."
— Paul Graham (http://paulgraham.com/todo.html)

“A distributed system is one where a machine I’ve never heard of can cause my program to fail.”
— Leslie Lamport

“It's important for nerds to realize, too, that school is not life. School is a strange, artificial thing, half sterile and half feral. It's all-encompassing, like life, but it isn't the real thing. It's only temporary, and if you look, you can see beyond it even while you're still in it.”
— Paul Graham, Hackers & Painters: Big Ideas from the Computer Age

“One of the lessons we learned from running the pilot groups of the course, was that developing small projects was a good way to shift yourself out of a rut and back onto the rapid part of the learning curve. In the full course, which we’ll open for a new session after these lessons, we’ll be guiding a new set of students through the process of designing and executing their own deliberate practice projects.”
— Scott Young (Top Performer course)

“In the meantime, ask yourself this: Are your the skills that matter for having a career you love improving as you’d like? If not, how could you improve the speed and quality of feedback you get to escape the Doctor’s Paradox.”
— Scott Young (Top Performer course)

“ninety percent of everything is crap”
— Sturgeon's revelation (Sturgeon's law)

“90% of everything is crap. That is true, whether you are talking about physics, chemistry, evolutionary psychology, sociology, medicine—you name it—rock music, country western. 90% of everything is crap.”
— Daniel Dennett

“We are what we pretend to be, so we must be careful about what we pretend to be.”
— Kurt Vonnegut

“Most things are bullshit - don't trust mass opinion”
— Pieter Hintjens

“Most people spend more time and energy going around problems than trying to solve them.”
— Henry Ford

“When the facts change, I change my mind. What do you do, sir?”
— John Maynard Keynes

Some good quotes coming from go course materials #

"The software business is one of the few places we teach people to write before we teach them to read."
— Tom Love (inventor of Objective C)

"Code is read many more times than it is written."
— Dave Cheney

"Programming is, among other things, a kind of writing. One way to learn writing is to write, but in all other forms of writing, one also reads. We read examples both good and bad to facilitate learning. But how many programmers learn to write programs by reading programs?"
— Gerald M. Weinberg

"Skill develops when we produce, not consume."
— Katrina Owen

"There are two kinds of software projects: those that fail, and those that turn into legacy horrors."
— Peter Weinberger (inventor of AWK)

"Legacy software is an unappreciated but serious problem. Legacy code may be the downfall of our civilization."
— Chuck Moore (inventor of Forth)

"Few programmers of any experience would contradict the assertion that most programs are modified in their lifetime. Why then do we rarely find a program that contains any evidence of having been written with an eye to subsequent modification.
— Gerald M. Weinberg"

"We think awful code is written by awful devs. But in reality, it's written by reasonable devs in awful circumstances."
— Sarah Mei

"There are many reasons why programs are built the way they are, although we may fail to recognize the multiplicity of reasons because we usually look at code from the outside rather than by reading it. When we do read code, we find that some of it gets written because of machine limitations, some because of language limitations, some because of programmer limitations, some because of historical accidents, and some because of specifications—both essential and inessential."
— Gerald M. Weinberg

"Let's imagine a project that's going to end up with a million lines of code or more. The probability of those projects being successful in the United States these days is very low - well under 50%. That's debatable."
— Tom Love (inventor of Objective C)

"100k lines of code fit inside a box of paper."
— Tom Love (inventor of Objective C)

"One of our many problems with thinking is “cognitive load”: the number of things we can pay attention to at once. The cliche is 7±2, but for many things it is even less. We make progress by making those few things be more powerful."
— Alan Kay

"The hardest bugs are those where your mental model of the situation is just wrong, so you can't see the problem at all."
— Brian Kernighan

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
— Brian Kernighan

"Debuggers don't remove bugs. They only show them in slow motion."
— Unknown

"Fixing bugs is just a side effect. Debuggers are for exploration."
— @Deech (Twitter)

"Make it correct, make it clear, make it concise, make it fast. In that order."
— Wes Dyer

"Good engineering is less about finding the "perfect" solution and more about understanding the tradeoffs and being able to explain them."
— JBD

"Choosing the right limitations for a certain problem domain is often much more powerful than allowing anything."
— Jason Moiron

"The correctness of the implementation is the most important concern, but there is no royal road to correctness. It involves diverse tasks such as thinking of invariants, testing and code reviews. Optimization should be done, but not prematurely."
— Al Aho (inventor of AWK)

"The basic ideas of good style, which are fundamental to write clearly and simply, are just as important now as they were 35 years ago. Simple, straightforward code is just plain easier to work with and less likely to have problems. As programs get bigger and more complicated, it's even more important to have clean, simple code."
— Brian Kernighan

"Problems can usually be solved with simple, mundane solutions. That means there's no glamorous work. You don't get to show off your amazing skills. You just build something that gets the job done and then move on. This approach may not earn you oohs and aahs, but it lets you get on with it."
— Jason Fried

"An architecture isn't a set of pieces, it's a set of rules about what you can expect of them."
— Michael Feathers

"Mistakes are an inevitable consequence of doing something new and, as such, should be seen as valuable; without them, we'd have no originality."
— Ed Catmull (President of Pixar)

"It takes considerable knowledge just to realize the extent of your own ignorance."
— Thomas Sowell

"Failure is expected, failure is not an odd case. Design systems that help you identify failure. Design systems that can recover from failure."
— JBD

"Product excellence is the difference between something that only works under certain conditions, and something that only breaks under certain conditions".
— Kelsey Hightower

"Instability is a drag on innovation."
— Yehudah Katz

"This is a cardinal sin amongst programmers. If code looks like it’s doing one thing when it’s actually doing something else, someone down the road will read that code and misunderstand it, and use it or alter it in a way that causes bugs. That someone might be you, even if it was your code in the first place."
— Nate Finch

"Can you explain it to the median user (developer)? as opposed to will the smartest user (developer) figure it out?"
— Peter Weinberger (inventor of AWK)

"Making things easy to do is a false economy. Focus on making things easy to understand and the rest will follow."
— Peter Bourgon

"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
— Edsger W. Dijkstra

"Everything should be made as simple as possible, but not simpler."
— Albert Einstein

"You wake up and say, I will be productive, not simple, today."
— Dave Cheney

Paraphrasing: "Encapsulation and the separation of concerns are drivers for designing software. This is largely based on how other industries handle complexity. There seems to be a human pattern of using encapsulation to wrestle complexity to the ground."
— Brad Cox (inventor of Objective C)

"The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise"
— Edsger W. Dijkstra

"Computing is all about abstractions. Those below yours are just details. Those above yours are limiting complicated crazy town."
— Joe Beda

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
— Donald E. Knuth

"I don't trust anything until it runs... In fact, I don't trust anything until it runs twice."
— Andrew Gelman (one of the greatest living statisticians at Columbia University).

"When we're computer programmers we're concentrating on the intricate little fascinating details of programming and we don't take a broad engineering point of view about trying to optimize the total system. You try to optimize the bits and bytes."
— Tom Kurtz (inventor of BASIC)

"Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorthims, are central to programming."
— Rob Pike

“If we take care of the moments, the years will take care of themselves.”
— Maria Edgeworth

Talks I like: #

Ideas: #

Best Books: #



Share on Hacker News
Share on LinkedIn


← Home