프로그래밍이 어려운 이유 - 프로그래밍이란 도대체 무엇인가?

※ 주의: 의역 있음

 

Why programming is hard

A computer is an idiot box. It can execute only the simplest of instructions natively, like: Add 42 to this number.
(컴퓨터는 멍청한 상자다. 이 기계는 오직 "이 변수에 42를 더하라."와 같은 단순한 명령만을 이해한다.)

Because of this limitation, every real world problem needs to be decomposed and then decomposed again until we have written down the entire process in instructions so simple that even the idiot box can understand them.
(
이러한 한계로 인해, 모든 현실의 문제들은 바보 상자가 이해할 수 있는 단순한 명령어만으로 프로세스 전체를 작성할 수 있을 만큼 분해되고 또 분해되어야 한다.
)

But why is programming hard?
(이것이 왜 코딩을 어렵게 만드는가?)

One of the reasons is that while decomposing the problem into myriads of simple instructions, it matters how many of these simple instructions we generate. That means that a smarter translation of the problem into fewer instructions is often better if not outright required. And that smarter translation often requires non-trivial insights from the world of mathematics.
(
한 가지 이유는, 가지각색의 방법으로 현실의 문제를 간단한 명령어 조합으로 분해할 때, 얼마나 많은 명령어가 사용되는지가 중요하다는 것이다. ※ 컴퓨터가 아무리 빨라도 공학적 한계가 있다는 뜻이다. 이를 해결하기 위해 수많은 비직관적인 알고리즘 이론과 훈련이 요구된다.
)

Another reason is that we usually don’t understand the original problem very well. Programmers have to cater for every possible exceptional situation, even if they are very rare, even if they occur only once in a lifetime: Your program will have to deal with it or fail.
(
또 다른 이유는, 대부분의 경우 우리는 원래의 문제를 잘 이해하지도 못한다는 것이다. 프로그래머는 가능한 모든 예외적인 상황을 알고 대처해야 한다. 심지어 그것이 드물거나, 혹은 평생 한 번 겨우 볼 만큼 희귀하게 일어난다고 해도 그 예외 상황으로 인해 프로그램은 죽는다.
)

Even when we think we understand a problem, we don’t. Sometimes this is because the world is very complicated  (or at least very diverse). This leads to incorrect assumptions such as “everybody knows their date of birth”,“people live in a place that has a street address”
(
문제는 우리가 이 정도면 문제가 전부 분석되었다고 착각하는 것이다. 결국 무의식적으로 잘못된 가정을 한다. 그러나 현실의 문제는 매우 복잡하고 예외적다. 예를 들어, "모든 사람은 자신의 생일을 알고 있을 것이다.", "모든 사람들은 주소가 부여된 곳에 살 것이다."와 같은 가정들 말이다.
)

Even if you completely understand the problem, programming means getting every detail exactly right. The idiot box does exactly what you told it to do, not what you meant for it to do.
(
설령 모든 상황을 전부 장악했다고 해도, 소스 코드는 단 하나의 실수 없이 완벽하게 작성되어야 한다. 특히 컴파일 타임에 확인할 수 없는 버그는 까다롭다. 예를 들어, 문자열로 작성된 숫자 데이터를 숫자 데이터 타입이라고 착각하고 더하기 연산을 시도할 때, 그러한 문법을 허용하는 프로그래밍 언어에서는 버그를 잡기 힘들다.
)

A design choice, once made, is more often than not set in stone for all of eternity, leaving programmers to deal with the resulting complexity and confusion. For example, as parts of the system get (re-)written in newer programming languages, we are still beholden to choices made in the past because the new programs needs to exchange data with existing older programs that don’t know any better.
(
또 다른 이유로는, 한 번 결정된 디자인은 일단 한 번 결정되면 나중에 수정하기 매우 힘들다는 것이다. 예를 들어, 많은 문제가 개선된 새로운 프로그래밍 언어를 사용하려고 해도, 기존에 사용하던 다른 시스템과 호환이 안 되거나, 해석하지 못하는 데이터 타입으로의 변환 문제가 발생할 수도 있다.
)

Another problem is that the designers of new programming languages don’t get everything right on Day One, which leads to changes in the language in order to fix any design mistakes. But alas..! in order not to annoy existing users of the language, the fixes are either complicated hacks on top of the existing system or a complete additional module (with lots of duplicate functionality).
(
기존 문제를 개선한다고 해도 그 자체로 문제가 된다. 거의 모든 개발자들은 처음부터 완벽한 설계를 할 수 없다. 그러나 하위 버전과의 호환성을 위해 예전에 실패했던 디자인을 계속 유지해야 할 수도 있다. 이것은 문제의 개선이 기존 시스템을 전혀 바꾸지 못하고 그저 새로운 것만 얹어버리는 결과를 낳는다. 예를 들어, 아스키코드가 오직 영어 알파벳만을 수용하면서 벌어진 문제를 생각해보라. 나중에 한국어, 중국어, 아랍어 운영체제가 필요하게 되었을 때 온갖 가지각색의 인코딩이 범람하게 되면서 문자 데이터가 깨지게 된 것이다.
)

We are constantly faced with problems great and small that have their origins in choices that were made in the past and that we cannot get away from unless we are willing to revisit and fundamentally address them. In that sense programming is very much like constantly rebuilding a century old house.
(
또한 우리가 마주하는 크고 작은 개선 모두 과거의 설계 선택에 의존한다. 그래서 우리는 어떤 문제를 해결하기 위해 설계의 근본부터 이해하지 못하면 안 되는데, 문제는 우리에겐 그럴 시간과 에너지가 없다는 것이다. 그래서 많은 프로그래밍 작업은 낣은 집을 계속 수리하는 것과 같다. 처음부터 멋진 건물을 세우지 못했기 때문에 낡은 통나무 집에 최신식 세면대를 만들고, 전에 썼던 낡은 냉장고를 설치하고, 자리가 부족하면 벽을 부수고, 부순 자리에 진흙으로 벽돌을 만드는 셈이다.
)

The number of different factors that conspire to make the life of a software engineer more difficult than it theoretically needs to be, could easily fill a weighty text book, which will obviously never be written because we have enough trouble as it is getting people to study computer science :-)
(
이러한 문제들이 개선된다고 해도 그 모든 이해를 컴퓨터 사이언스 과목에 추가할 수 없다. 이미 엄청난 지식의 양에 시달리고 있기 때문이다.
)

The fact that programming is hard makes it fun and rewarding! When programming you are pitching your intellect against the complexity of an entire universe with nothing more than math and an idiot box to help you solve the problem. If only there were no deadlines…
(
프로그래밍의 이러한 한계들이 우리의 작업을 더 재밌게 만든다. 우리는 항상 우리의 지적 한계를 시험하며, 오직 수학과 멍청한 박스만을 사용해 세상의 복잡함을 상대해야 하므로. 물론 데드라인이 없다면...
)

 

---

 

#. 이래도 진정 소프트웨어를 개발하고 싶은가?

 

No, you don’t want an app

Everyone keeps reading about how coding is fun and easy. Even kids can do it. There are thousands of apps already, so developing an app cannot be that hard. Because, surely, how hard can that be?.....
(
사람들은 코딩이 얼마나 쉽고 재밌는지 이야기하는 것을 듣는다. 심지어 아이들도 코딩을 배울 수 있다고 말하지 않는가. 게다가 우리는 이미 수많은 앱을 사용하고 있지 않은가! 앱 개발은 그렇게 어렵지 않아 보인다.. 하지만 정말 그럴까?
)

The apps that most people use on a daily basis, and which set their expectations for all apps they use, are super slick affairs that have been developed by armies of people (not just software engineers) at considerable cost, typically over years of ongoing development.
(
우리가 일상적으로 사용하는 앱들은 우리의 앱의 평균에 대한 기준을 형성했다. 그러나 그런 '적당해 보이는' 앱들은 소프트웨어 전문가뿐만 아니라 수많은 기술을 가진 사람들이 모여 엄청난 비용을 들어 만든 것이며, 지금까지 지속적으로 업데이트되어 온 것이다.
)

I love the Uber app; it’s great. But apparently it has two hundred people working on it. Full time. Imagine each of these cost the company $250,000 per year in total cost of employment (a conservative estimate), that means Uber pays $50 million per year for their app. Not surprising then that he app is great. (Now people probably want an app that does only 1% of what the Uber app does. But that would still cost $500k per year...)
(
우버앱을 예로 들어보자. 우버는 200명의 사람들이 풀타임으로 일해서 개발한 것이다. 각 사람마다 회사가 연봉으로 평균 $250,000 (약 3억 2천만원)을 지불한다..! 이것도 보수적인 추정치다. 즉, 우버는 그들의 앱을 위해 연간 $50,000,000 (약 657억원)을 지불한다는 것을 의미한다. 그럼 이제 아마도 우버 앱이 하는 일의 1%만 하는 앱을 원할 것이다. 그러나 그것도 여전히 연간 $500,000 (약 6억 5천만원)이 들 것이다...
)

One of the things to note here is that the Uber app probably has a hundred features whereas I as a rider use only two of them. The other 98 features are for Uber drivers and for things that I never use such as splitting the bill, informing other people about my ride, getting an invoice, canceling a ride, and Uber pool. Apps are like icebergs: The vast majority of the mass sits below the waterline where most people don’t see it. The app developer however has to develop and maintain that part too. You might have to spend a lot of money for pieces of app that not many people use but without which your app would be considered substandard.
(
여기서 주목해야 할 점 중 하나는 우버 앱이 약 100가지 기능을 가지고 있다고 하면, 일반 사람들은 그 중 두 가지 기능만 사용한다는 것이다. 나머지 98가지 기능은 우버 운전자를 위한 것으로, 요금 쪼개기, 다른 사람들에게 내가 타는 것에 대해 알려주기, 송장 받기, 취소하기, 그리고 우버 풀과 같이 내가 절대 사용하지 않는 것들을 위한 것이다. 앱은 빙산과 같다. 대다수 기능은 대부분의 사람들이 보지 못하는 수면 아래에 위치한다. 하지만 앱 개발자는 그 부분도 개발하고 유지해야 한다. 여러분은 많은 사람들이 사용하지 않는 기능을 위해 많은 돈을 써야 하고, 그렇지 않으면 당신의 앱은 표준 이하로 간주될 것이다.
)

Changing tracks for a second: If you go and look at a skyscraper being built you immediately understand two things:
1. This is difficult.
2. This is expensive.
(초고층 빌딩을 보면 당신은 두 가지를 직접 깨닫는다. 초고층 빌딩을 건축한다는 것은 매우 어렵고, 매우 비싸다!)

Compared to building skyscrapers, the cost and complexity of app development is impossible to estimate for the layperson. Everybody who has ever assembled an Ikea cabinet knows that building solid stuff is hard. But nobody who has ever created a spreadsheet or used an app has any idea how much time and effort it took to get that software together. It’s just not obvious. No concrete to pour, no piles to drive, no cranes to rent. It’s all just zeros and ones in the right order. Sure, probably a lot of zeros and ones, but really how hard can it be to get all the zeros and ones you need and put them in the right order?
(
하지만 초고층 빌딩을 짓는 것에 비해 앱 개발의 비용과 복잡성은 일반인에게는 추정이 불가능하다. 이케아 캐비닛을 조립해 본 적이 있는 사람은 캐비닛조차 견고하게 만드는 것이 어렵다는 것을 안다. 하지만 엑셀과 같은 사용자 앱을 사용해 본 적이 있는 사람은 소프트웨어를 조립하는 데 얼마나 많은 시간과 노력이 필요한지 전혀 추정하지 못한다. 직관적으로 명확하지 않다. 콘크리트도 없고, 운송할 것도 없고, 크레인도 없다. 그저 0과 1이다. 물론 많은 0과 1이 필요하지만, 필요한 모든 0과 1을 생각하고 올바른 순서로 놓는 것이 얼마나 어려운지 상상해볼 수 있는가?
)

And to make matters worse, you probably need to develop two apps: One for the iPhone and one for Android phones. This won’t probably cost twice as much as developing one app, because if you have your stuff together you can reuse code from one app in the other, but my guess is that it is at least 1.3–1.5 times as expensive as developing a single platform app.
(
그리고 설상가상 당신은 아마도 안드로이드와 iPhone 플랫폼을 서비스하기 위해 앱을 두 개씩 개발해야 할 것이다. 물론 하나의 앱을 개발하는 것보다 정확히 두 배의 비용이 들지는 않는다. 왜냐하면 소스 코드를 재사용할 수 있기 때문이다. 하지만 그럼에도 불구하고 하나의 플랫폼 앱을 개발하는 것보다 적어도 1.3~1.5배는 더 비쌀 것이다.
)

"Can’t we get a cheap student from <prestigious university> to code the app. They are good (because: <prestigious university>) and they are cheap (because: student)...?"
(
당신은 이렇게 생각할지도 모른다.
"명문대에서 저렴한 학생을 구해 앱을 코딩할 수는 없을까요? 그들은 (명문대 출신이니까) 좋고, (학생이니까) 저렴하기 때문에…."
)

This is an understandable thought. But, like most things that seem obvious, it doesn’t work. Ask yourself this: Would you have your house built entirely by apprentices from your local community college or vocational school? Sure they might be useful for odd jobs here and there, but would you have them do the structural design? Get the permits? Ensure your house meets the building code? Take care of the electricity and the gas?
(
이것은 이해할 수 있는 논리지만, 명백히 효과가 없다. 스스로에게 이렇게 물어보라: 여러분의 집은 전적으로 전문 대학 또는 명문대를 갓 졸업한 학생에 의해 지어지는가? 물론 그들은 여기저기 잡일에는 유용할 수 있지만, 여러분은 그들이 구조 설계를 하도록 할 것인가? 갓 졸업한 학생들이 건축 허가증을 얻을 수 있는가? 여러분의 집이 건축 법규를 충족하는지 그들이 확인할 수 있는가? 전기와 가스를 안전하게 다룬다고 확신할 수 있나?
)

Software development works just like building a house: It takes a lot of experience to do it well. It doesn’t look as dramatic because people don’t get killed when the software equivalent of the roof caves in, but experience in how to do things and how to do them right matters. And experience costs money. I have met lots of super bright students from prestigious universities and some of them could code like daemons. But coding is to software development what carpentry and plumbing are to building a skyscraper: It needs lots of it and it better be good, but all things considered these are just two of the umpteen things which need to be done right in order to finish the project successfully and on time/budget.
(
소프트웨어 개발은 집을 짓는 것과 마찬가지다. 잘 하려면 많은 경험이 필요하다. 물론 지붕을 잘못 짓는 것은 사람을 죽일 수 있으나, 소프트웨어가 사람을 죽이지 않기 때문에 그렇게 극적으로 보이지는 않지만, 어떻게 일을 하고 올바르게 할 수 있는지에 대한 경험은 여전히 중요하다. 그리고 경험은 비용이 든다. 나는 명문 대학에서 매우 똑똑한 학생들을 많이 만났고, 그들 중 일부는 코딩을 정말 잘 한다. 하지만 소프트웨어 개발에서 코딩은 빌딩 건설에 있어 목공과 배관과 같은 것이다. 물론 그러한 작업이 필요하고, 또 잘하면 더 좋긴 하겠지만, 이것들은 단지 전체 프로젝트를 제 시간과 예산에 성공적으로 마치기 위해 올바르게 수행해야 할 고작 한 두 가지 일에 불과하다.
)

If what you need is really, really, simple, you might want to look at bubble.io, kissflow.com, or similar app development platforms. Disclaimer: I have never used any of these and I am generally not optimistic about what these sort of tools can deliver. But, maybe they are awesome.
(
필요한 것이 정말로, 정말로, 간단한 것이라면 bubble.io , kissflow.com 또는 이와 유사한 앱 개발 플랫폼을 보는 것이 좋을 것이다. 잠깐! 나는 이것들 중 어떤 것도 사용해 본 적이 없으며 일반적으로 이러한 종류의 도구가 제공할 수 있는 것이 무엇인지 아주 낙관적이지는 않다. 그러나 아마도 그것들은 굉장할 것이다.
)

If app development were cheap and easy, where would people like me find the money to buy yachts and planes? :-)
( 앱 개발이 저렴하고 쉬웠다면 전문 개발자들이 요트와 비행기를 살 돈을 어디서 구한다고 생각하는가? :-) )

 

---

 

 

Why is Programming so Difficult? - LearnHub

The conceptual complexity required in programming also proves extremely challenging.
(
개념적 복잡성은 적절한 구문 외에도 매우 어려운 것으로 입증된다.
)

Computing architecture has many layers of abstraction built on top of the actual machine code executed. As a programmer, you must operate at these higher conceptual levels while understanding how code corresponds to actual hardware operations.
(
컴퓨팅 아키텍처는 실행된 실제 기계 코드 위에 많은 추상화 계층이 구축되어 있다. 프로그래머로서 코드가 실제 하드웨어 연산에 어떻게 대응되는지 이해하면서 이러한 상위 개념 수준에서 연산해야 한다.
)

Some of the abstract programming concepts that often pose difficulty include
- Data structures: choosing the optimal data structures for tasks.
- Algorithms: developing efficient and logical algorithms.
- Object-oriented paradigms: models of real-world objects and interactions.
- Concurrency: dealing with simultaneous operations and threads. (비동기, 멀티스레드)
- Design patterns: recognizing common abstract solutions to frequent issues.
- Architecture: understanding how code interacts with systems architecture.

According to a study by the University of Washington, failure to master programming abstraction concepts was a leading factor among students who dropped out of an intro course.
(
워싱턴 대학교의 한 연구에 따르면, 프로그램 추상화 개념을 숙달하지 못한 것이 인트로 과정을 중퇴한 학생들의 이탈 요인이었다.
)

The intense abstraction required strains the cognitive mind of new learners. Developing this high-level conceptual mastery takes time and experience. But it enables programmers to build complex, scalable programs.
(
강도 높은 추상화는 새로운 학습자들의 인지적인 마음을 압박한다. 이 높은 수준의 개념적 숙달을 개발하는 것은 시간과 경험이 필요하다. 그러나 그것은 프로그래머들이 복잡하고 확장 가능한 프로그램들을 만들도록 한다.
)

 

---

 

 

Martin's blog - Why programming is hard

<전문>

I have been giving programming languages a lot of thought recently. And it has ocurred to me that the reason why (reportedly) lots of people fail at learning how to program is because they are introduced to it at entirely the wrong level.
: 저는 최근 프로그래밍 언어에 대해 많은 생각을 하고 있습니다. 그리고 많은 사람들이 프로그래밍 언어를 배우는 데 실패하는 이유가 완전히 잘못된 수준에서 프로그래밍 언어를 접했기 때문이라는 생각이 들었습니다.

If you as a beginner search "Python tutorial" right now, you will get lots of very detailed, completely correct, very polished tutorials that will teach you how to program in Python, but that will not teach you how to program. Conversely, if you search for "how to program", the first results will be either completely useless advice such as "decide what you would like to do with your programming knowledge" or they ask you to choose a programming language. You might choose Python, in which case you are now back to square one.
: 만약 당신이 지금 "파이썬 튜토리얼"을 초보자로 검색한다면, 당신은 파이썬으로 프로그래밍하는 방법을 알려줄 매우 상세하고, 완전히 정확하며, 매우 세련된 튜토리얼을 많이 얻을 것이지만, 그것이 당신에게 "프로그래밍" 방법을 가르쳐주지는 않을 것입니다. 반대로 "프로그래밍하는 방법"을 검색한다면, 즉시 볼 수 있는 결과는 "프로그래밍으로 무엇을 하고 싶은지 결정하라"와 같은 완전히 쓸모없는 조언이거나, 프로그래밍 언어를 선택하라고 요구할 것입니다. 당신은 파이썬을 선택할 것이고, 이 경우 당신은 결국 다시 원점으로 돌아갑니다.

One of the founding principles of my field is that "Computer Science is no more about computers than astronomy is about telescopes". In other words, programming is a skill that it's expressed typicall using programming languages, but it's not exclusively about them. And programming, the skill underlying all of these programming languages, is hard.
: 제 분야(컴퓨터과학)의 기반 원리 중 하나는 "천문학이 망원경에 관한 것이 아닌 것처럼, 컴퓨터과학도 컴퓨터(기계)에 관한 것이 아니다"라는 것입니다. 즉 프로그래밍은 프로그래밍 언어를 사용하여 표현되는 기술이지만, 그것만이 전부가 아닙니다. 그리고 이 모든 프로그래밍 언어의 기초가 되는 기술인 '프로그래밍'은 어렵습니다.

To be a good programmer, you need to master three related skills:
좋은 프로그래머가 되기 위해서는 다음과 같은 세 가지 관련 기술을 숙달해야 합니다.

1. Understand how to convert messy real-life problems into a clearer version with less ambiguities.
: 지저분한 실생활의 문제를 모호성은 적고 더 명확한 버전으로 변환하는 방법을 이해한다.

2. Understand what the best practical approach to this problem is, and choose one as a possible solution.
: 이 문제에 대한 가장 실용적인 접근법이 무엇인지 이해하고, 가능한 해결책으로 하나를 선택한다.

3. Understand how to use programming languages and data structures to implement that solution.
: 그 솔루션을 구현하기 위해 프로그래밍 언어와 데이터 구조를 사용하는 방법을 이해한다.

Mastering the first skill requires an analytical mind, and in particular forces you to see the world in a different way. If someone asks you for a program to keep track of how many people are inside a room, you need to stop thinking in terms of people and rooms and think in terms of numbers and averages. You also need to account for badly-defined situations: if a woman gives birth inside the room, is your solution good enough to increase the room count by one?
: 첫 번째 기술을 습득하는 것은 분석적인 사고를 요구하며, 특히 세상을 다른 방식으로 보도록 요구합니다. 만약 누군가가 여러분에게 방 안에 얼마나 많은 사람들이 있는지를 기록하는 프로그램을 요청한다면, 여러분은 사람들과 방의 관점에서 생각하는 것을 멈추고 숫자와 평균의 관점에서 생각해야 합니다. 여러분은 또한 불분명한 상황들도 설명할 필요가 있습니다: 만약 여성이 방 안에서 출산을 한다면, 여러분의 솔루션이 카운트를 하나 늘릴 만큼 효과적인 솔루션인가요?

This part alone is quite hard. Some people make a living out of it as software requirements engineers, meeting with clients and discussing some approaches that would make sense. It also requires at least a surface level understanding of the type of solutions that one could realistically employ. If you ever wondered why your high-school math teacher always asked you to turn apples and trains into equations and solving for x, well, this is why: they were teaching you how to solve real-world problems with simpler methods.
: 이 부분만 놓고 봐도 꽤 어렵습니다. 심지어 어떤 사람들은 소프트웨어 "요구사항" 엔지니어로서, 고객을 만나 합리적인 몇 가지 접근법에 대해 논의하는 것에 전문적으로 종사합니다. 또한 이것은 어떤 유형의 솔루션을 현실적으로 사용할 수 있는지에 대한 최소한의 표면적인 이해를 필요로 합니다. 고등학교 수학 선생님이 왜 항상 사과와 기차를 방정식으로 바꾸고 x를 위해 풀라고 했는지 궁금했던 적이 있다면, 이것이 바로 그 이유이죠. 그들은 실제 문제를 더 간단한 방법으로 해결하는 방법을 가르쳐주고 있었던 것입니다.

In order to master the second skill "choose a viable solution", you need to read a lot about which problems are easy and which ones are hard. There are some problems that a programmer solves daily, and some problems for which the best known solution would still take thousands of years. If you think that finding new solutions to problems is interesting, I encourage you to go knock at the Math department of your nearest university. They do this for a living, and will be very excited to have you around.
: 두 번째 기술 "실행 가능한 해결책 선택"을 숙달하기 위해서는 어떤 문제가 쉽고 어떤 것이 어려운지에 대해 많이 읽어야 합니다. 프로그래머가 매일 해결하는 문제도 있고, 가장 잘 알려진 해결책을 찾는 데 앞으로도 수천 년이 걸릴 문제도 있습니다. 이런 문제에 대한 새로운 해결책을 찾는 것이 흥미롭다고 생각한다면 가까운 대학의 수학과에 가서 노크하는 것이 좋습니다. 그들이 이런 일을 하고, 여러분이 곁에 있는 것을 매우 기뻐할 것입니다.

Finally, the third and last skill "implement a solution" requires you to write it down in a way that computers can understand. Half the job requires understanding common concepts for structuring programs (variables, databases, data structures, networks, and so on), and the other half requires learning the syntax of your preferred programming language.
: 마지막으로 세 번째이자 마지막 기술인 "솔루션 구현"은 컴퓨터가 이해할 수 있는 방식으로 작성해야 합니다. 여기서 절반은 프로그램 구조화를 위한 공통 개념(변수, 데이터베이스, 데이터 구조, 네트워크 등)을 이해하는 것이고, 나머지 절반이 선호하는 프로그래밍 언어의 문법을 학습하는 것입니다.

And here we reach the core of this post's answer. If you type "Python tutorial" right now, what you'll get are very detailed guides on how to acquire the second half of the third skill, also known as "the unimportant one". Sure, programmers love discussing which programming language is better and how not to write code, but here's a little secret: in the larger scale of things, it rarely matters. Some programming languages are better suited for specific tasks, true, but the best programming language is not going to be of any help if you don't know what you are trying to build.
: 그리고 여기서 우리는 이 포스트의 답의 핵심에 도달합니다. 지금 "파이썬 튜토리얼"을 입력하면 세 번째 기술, 그것도 후반부를 습득하는 방법, 즉 "중요하지 않은 것"에 대한 매우 상세한 가이드를 볼 것입니다. 물론 프로그래머들은 어떤 프로그래밍 언어가 더 나은지, 그리고 코드를 작성하지 않는 방법에 대해 논의하는 것을 좋아하지만 여기에 약간의 비밀이 있습니다. 더 큰 규모의 작업에서는 별로 중요하지 않다는 것이죠. 특정 작업에 적합하다고 알려진 일부 프로그래밍 언어가 있긴 하지만, 당신이 무엇을 만들려고 하는지 모른다면 최고의 프로그래밍 언어를 선택하고 배워봤자 아무런 도움이 되지 않습니다.

At its core, programming is learning how to solve problems with a specific set of tools. And while you do need to understand how to use those tools, they are completely useless if no one explains to you how to solve problems with them. If knowing how to use a pen doesn't make you a writer, and knowing how to use a wrench doesn't make you a mechanic, teaching you a programming language and expecting you to become a programmer overnight is just going to leave you confused and frustrated. But remember: it's not you, it's them.
: 프로그래밍의 핵심은 특정 도구 세트로 문제를 해결하는 방법을 배우는 것입니다. 그리고 도구 사용법을 이해해야 하지만, 아무도 문제를 해결하는 방법을 설명해주지 않으면 도구는 완전히 쓸모가 없습니다. 펜 사용법을 알고 있다고 해서 작가가 되는 것은 아니고, 렌치 사용법을 안다고 해서 정비공이 되는 것은 아니므로 프로그래밍 언어를 가르치고 하루아침에 프로그래머가 되기를 기대하는 것은 혼란스럽고 좌절감을 줄 것입니다. 하지만 기억하세요: 그것은 당신이 아니라 그들입니다.


Appendix: What does problem solving looks like?
부록: 그렇다면 문제 해결이란 어떤 모습일까요?

Let's say someone asks me to "write a program to know who I have been in contact with in any given day", a problem known as contact tracing that has been in the news in the past weeks. How would the skills above come into play?
: 누군가가 당신에게 "어떤 특정한 날에 내가 누구와 접촉했는지 알 수 있는 프로그램을 작성해달라"고 요청한다고 가정해 봅시다. 이 문제는 지난 몇 주 동안 뉴스(코로나)에 등장했던 접촉자 추적이라는 문제입니다. 제가 위에서 말한 프로그래밍 스킬이 어떻게 적용되는지 봅시다.

(Note: for the sake of simplicity, I am going to solve this problem badly. It's a toy example, so don't @ me!)
(참고: 단순성을 위해서, 이 문제를 나쁘게 풀 것입니다. 장난감 사례에 불과하므로, 태클하지 않기를!)

The first step is to model this situation in a formal, more structured way. Real people are difficult to work with, but luckily we don't care about most things that make them human - all we care about is where they have been at any point in time. Therefore, we replace those real people with "points", keep track of their GPS coordinates at all times, and throw all of their remaining attributes away.
: 첫 번째 단계는 공식적이고 더 체계적인 방식으로 이 상황을 모델링하는 것입니다. 실제 사람들에게 무언가를 하기는 어렵지만, 운 좋게도 우리는 인격적인 정보들에는 관심이 없습니다 - 우리가 관심을 갖는 것은 그들이 어느 시점에서 어디에 있었는가(위치 정보) 입니다. 그러므로, 우리는 그 사람들을 "점"들로 변환하고, 그들의 GPS 좌표를 추적하고, 사람들에게 남아있는 다른 정보들은 버립니다.

We have now turned our problem into "tell me which GPS coordinates (i.e., points) have been close to my GPS coordinates at any given time". We can simplify the problem further by defining what "close to me" means, and we turn the problem into "give me a list of points that have been 1 meter or closer to me at any given time".
: 이제 우리는 우리의 문제를 "어떤 주어진 시간에 어떤 GPS 좌표가 나의 GPS 좌표에 근접했는지 알려달라"는 식으로 바꿨습니다. 우리는 "나와 가까운" 것이 무엇을 의미하는지 정의함으로써 더 단순화할 수 있습니다. 이제 문제는 "어떤 주어진 시간에 나로부터 1미터 내로 근접한 좌표들의 목록을 달라"는 식으로 바꿨습니다.

Next, we need to find a way to efficiently identify which points have been close enough to our coordinates. Since there is a lot of people in the world, we start by crudely removing all points that are more than 10km. away from me - this can be done very quickly, and it probably won't affect our results too badly.
: 다음으로, 우리는 어떤 좌표들이 우리의 좌표에 충분히 근접했는지를 효율적으로 식별할 수 있는 방법을 찾아야 합니다. 세상에는 많은 사람들이 있기 때문에, 우리는 10킬로미터 이상 떨어진 지점들을 조잡하게나마 제거하는 것부터 시작합니다. - 이것은 매우 빠르게 이루어질 수 있고, 아마도 우리의 결과에 너무 큰 영향을 미치지 않을 것이다.

We now need to refine our search, and therefore we take a dive into the geometry literature. After a quick look, I decided that building a Quadtree is the best solution for what I want to build. Note that I only have a passing knowledge of what Quadtrees are, but that's fine: once I have a hint of where the solution might be, I can search further and learn the details as I go.
: 이제 검색을 세분화해야 하므로 기하학으로 들어가 보겠습니다. 잠시 기하학 책을 살펴본 후, 저는 쿼드트리(Quadtree)를 구축하는 것이 제가 구현하고자 하는 것에 가장 적합한 솔루션이라고 결정했습니다. 저에게는 쿼드트리가 무엇인지에 대한 간단한 지식밖에 없지만 그래도 괜찮습니다. 솔루션이 어디에 있는지 힌트를 얻을 수 있으니까요. 더 자세히 검색하면 자세한 내용을 배울 수 있습니다.

And finally we get down to writing code. If our programming language doesn't already include an implementation of a Quadtree data structure, we might have to do it ourselves. If we choose Python, for instance, we need to understand how to create a class, how to use lists of objects, and all those other implementation details that our Python tutorial has taught us. Similarly, storing the list of points will probably require a database. Each database has a different strong point but, as I said earlier, knowing which database to use is not as important as knowing that some database is the right tool.
: 그리고 마지막으로 코드 작성에 대해 알아보겠습니다. 프로그래밍 언어에 쿼드트리 데이터 구조 구현이 포함되어 있지 않다면, 우리는 그것을 직접 해야 할 수도 있습니다. 예를 들어, 우리가 파이썬을 선택한다면, 우리는 클래스를 만드는 방법, 객체 목록을 사용하는 방법, 파이썬 튜토리얼이 알려준 다른 모든 구현 세부 정보를 이해해야 합니다. 마찬가지로, 포인트 목록을 저장하려면 데이터베이스가 필요할 것입니다. 각각의 데이터베이스는 다른 장점을 가지고 있지만, 앞서 말했듯이, 어떤 데이터베이스를 사용할지 아는 것은 중요하지 않습니다. 어떤 데이터베이스가 올바른 도구인지 아는 것이 쓸모 없는 것처럼요.

Let's now picture the same exercise in revers: imagine I come to you and say "Write me a program to know who I have been in contact with in any given day. Here's a guide on how to use Quadtrees in Python". You wouldn't find that last bit of any use, would you?
: 이제 같은 연습문제를 거꾸로 생각해 봅시다. 제가 여러분에게 와서 "하루 중 누구와 접촉했는지 알 수 있는 프로그램을 작성해 주세요. 여기 파이썬에서 쿼드트리를 사용하는 방법에 대한 가이드가 있습니다." 마지막에 제가 말한 것이 아무런 가치가 없다는 것을 아시겠죠? ("파이썬"이 중요한 게 아니라 프로그래밍으로 문제를 해결하는 것이 더 중요하다는 의미)

 

---

 

 

From the learnprogramming community on Reddit

The most fundamental concepts in programming are Abstraction and Modularity. Good quality abstractions are essential for good programming. Some people seem to be able to do this and others not, even after years of experience. Abstractions are about finding the essential aspects of the problem you are trying to solve. Only about 10% of the population seems to be able to think in a way that will make them a good programmer. If you aren't one of that group, not much seems to make a difference. The world doesn't need any more shitty programmers, we have quite enough already. Many of them get 'promoted' into project 'management', where they can really gum up the works.
:
프로그래밍에서 가장 기본적인 개념은 추상화와 모듈성이다. 좋은 프로그래밍을 위해서는 양질의 추상화가 필수적이다. 어떤 사람들은 이것을 할 수 있고 어떤 사람들은 할 수 없는 것 같다. 추상화는 당신이 해결하려고 하는 문제의 본질적인 측면을 찾는 것이다. 인구의 약 10%만이 그들을 훌륭한 프로그래머로 만들 수 있는 방식으로 생각할 수 있는 것 같다. 당신이 그 그룹에 속하지 않는다면, 많은 것이 차이를 만드는 것 같지 않다. 세상에는 더 이상 허튼 프로그래머가 필요하지 않지만, 우리는 이미 충분히 있다. 그들 중 많은 사람들이 프로젝트 '경영'에 '승진'되고, 그곳에서 그들은 정말로 일을 부풀릴 수 있다.