https://medium.com/@bobofbellevue/can-an-old-programmer-learn-new-tricks-b2826f87faf3

저는 1985년부터 2010년까지 25년 동안 일했던 소프트웨어 업계로 돌아가기로 2023년 초에 이곳에서 결정했습니다. 경력 13년 차입니다. 58세에 그렇게 오랜 시간을 보낸 후 업계에 복귀하는 것이 현실적입니까?

소프트웨어 산업 재진입의 걸림돌

두 가지 문제로 인해 이전에 소프트웨어 산업으로의 복귀를 시도하지 못했습니다.

1. 기술력의 노후화
2. 잠재적 연령 차별

저는 2010년에 C++, SQL 데이터베이스 기술 및 MFC(Microsoft Foundation Classes)의 Windows 데스크톱 응용 프로그램 개발에 대한 자세한 지식을 가지고 떠났습니다. MFC, C++ 및 데스크톱 응용 프로그램 개발은 2010년까지 이미 노후화된 기술이었습니다. 저는 마지막 회사에 너무 오래 머물렀습니다. 한 번도 성공한 적이 없었고 폐업한 적도 없었습니다. 당시에는 수요가 많은 기술이 없었습니다. 하지만 우리 제품 라인의 작은 웹 기반 섹션에서 C#, HTML 및 CSS를 가르쳐 주었지만 아직 웹 개발에 자신이 없었습니다. 그래서 저는 부동산 업계로 뛰어들었습니다(다른 기사에 대한 긴 이야기입니다).

나이가 많은 구직자를 차별하는 연령 차별에 관해서는 어린 나이에 직접 참여했습니다. 나이가 많은 지원자를 인터뷰할 때 – 아마 40대였을 것입니다 – 저는 이 사람이 이 직업을 원하는 이유는 무엇입니까?, 그의 경력에 ​​무엇이 잘못되었습니까?, 그에게 무슨 문제가 있습니까? 우리는 항상 젊은 지원자를 선택했습니다. 각 팀원은 이전 항목을 독립적으로 배제했습니다.

DevSlopes 및 Epiphany의 발견

2023년 1월 초에 저는 DevSlopes.com 에서 풀 스택 웹 개발자 프로그램에 합류했습니다 . 마케팅 자료를 검토하면서 두 가지 사실을 깨달았습니다.

1. 대규모 고용주는 더 이상 컴퓨터 과학 학위를 요구하지 않습니다.
2. 프리랜서, 온라인, 재택근무의 세계에서 아무도 당신의 나이를 알 필요가 없습니다.

1985년에 제 학위는 커뮤니티 칼리지에서 나왔습니다. 데이터 처리 분야에서 AA 학위를 받았습니다. 우리는 은행이나 보험 회사를 위한 COBOL 프로그램을 작성하도록 훈련받았습니다. 오늘날에는 별로 관련이 없습니다. (제쳐두고: COBOL 프로그램의 장황함은 자체 문서화를 만들고 비서가 컴퓨터 프로그램을 작성할 수 있도록 합니다.)

대학 기반 컴퓨터 과학의 실패

대학의 컴퓨터 과학 학과는 변함없이 수학 학과에서 성장했습니다. 단순히 컴퓨터에 처음 관심을 보인 것은 수학 교수였기 때문입니다. 이 프로그램은 이 뜨거운 분야에서 지원자를 걸러내야 했기 때문에 수학과 물리학의 전제 조건에 몰두했습니다. 일부 좁은 상황을 제외하고 수학은 프로그래밍과 관련이 없습니다. 컴퓨터 과학이 영어과에서 성장했다면 세상은 더 나아졌을 것입니다. 좋은 영어 에세이를 구성하는 것은 수학에서 진행되는 것보다 프로그래밍과 훨씬 더 유사합니다.

결과적으로 이러한 컴퓨터 과학 프로그램은 시장에 적응하지 못했고 프로그래머에 대한 강력한 수요를 충족할 만큼 성장하지도 못했습니다. 수학 교수는 비즈니스에 대해 무엇을 알고 있습니까? 고용주들은 우선 H-1B 비자 프로그램을 통해 외국인을 고용하는 것으로 대응했습니다. 현지 시민을 훈련시키는 것보다 훈련된 외국인을 고용하는 것이 훨씬 저렴하고 빠릅니다. 최근 DevSlopes와 같은 대안 온라인 학교는 웹 개발자의 고용 수요를 충족시키기 위해 성장했습니다. 고용주는 최신 경험과 웹 프로젝트 포트폴리오를 선호하도록 고용 관행을 파악하고 변경했습니다.

지금까지의 DevSlopes 결과

이 글을 쓰는 지금 저는 DevSlopes 프로그램에 2주 동안 참여하고 있으며 하루에 4~6시간 작업하고 있습니다. 지금까지 나는 두 가지에 대해 매우 기쁘게 생각합니다.

1. DevSlopes 자료 및 조직의 품질
2. 내 오래된 기술 중 일부가 여전히 가지고 있는 관련성

향후 기사에서 DevSlopes에 대한 리뷰를 작성하겠습니다. 프로그램에 매우 만족하며 4~6개월 안에 완료할 것으로 기대한다고 말하는 것으로 충분합니다.

오래된 기술은 새로운 날을 봅니다

여전히 관련성이 있는 내 기술은 - 때때로 놀랍게도 - 다음과 같습니다.

1. UNIX 운영 체제에서 시작된 VI 편집기. VI의 장점을 이해하려면 VI를 사용해야 합니다. 불행히도, 나는 그것을 배우려고 시도하는 초보자를 권장하지 않습니다. 잘 배우려면 2년 정도 걸립니다. 일단 그 지점을 지나면 마치 자전거를 타는 것과 같습니다. 절대 잊지 못할 것이고 손가락이 저절로 날아갈 것입니다. VI를 사용하면 마우스를 건드리지 않고 파일을 편집할 수 있습니다. 마우스와 키보드 간에 컨텍스트를 지속적으로 전환하지 않아도 됩니다. 여기에는 텍스트 탐색 및 변경과 마우스 기반 편집기에는 없는 복잡한 작업 반복을 위한 매우 풍부한 명령 세트가 있습니다. VI를 다시 사용하게 되어 기쁩니다.
2. HTML/CSS — 저는 이전 경력에서 이러한 주제를 다루었습니다. 나는 나에게 유리하게 시작할 수 있는 적어도 그들에 대한 독서 지식을 가지고 있었다.
3. Javascript — 많은 교육 자료가 Javascript와 관련될 것이라는 것을 알 수 있습니다. 나는 과거에 약간의 Javascript를 작성했지만 일반적으로 C++ 및 객체 지향 언어와 관련이 있으므로 다시 익히는 데 문제가 없을 것입니다.
4. SQL 데이터베이스 — 내 25년 경력은 SQL의 우세 이전에도 항상 데이터베이스와 관련이 있습니다(참고: SQL은 "구조화된 쿼리 언어"를 의미합니다. SQL은 비서가 데이터베이스에서 정보를 검색하는 데 사용할 수 있는 장황한 언어로 설계되었습니다. SQL은 프로그래밍 방식으로 사용하기에는 끔찍한 해킹이지만 업계는 시간이 지남에 따라 효율적이고 사용하기 쉽게 만드는 도구를 완성했습니다.) 데이터베이스 테이블 간의 SQL 구문 및 팩터링 필드와 같은 기술은 여전히 ​​관련이 있습니다. MongoDB라는 제품을 배우게 될 것입니다. 이 제품은 저에게 새로운 제품이지만 여전히 SQL 기반입니다.
5. 디버깅 및 테스트 — 저는 항상 프로그래머가 자체 테스트를 수행하는 소규모 회사에서 일했습니다. 디버깅은 가능한 가장 효율적인 방법으로 프로그래밍 오류의 범위를 좁히는 프로세스입니다.

프로 디버깅 팁

여기에서 두 가지 프로 디버깅 팁을 알려드리겠습니다.

1. 귀하의 문제는 원본이 아닙니다. 누군가 전에 같은 문제로 어려움을 겪었습니다. 구글링하세요. 비결은 질문을 표현하는 올바른 방법을 찾는 것입니다. 다른 사람들이 어떻게 요청했을지 생각해 보십시오.
2. 여러 시간 동안 벽에 머리를 부딪쳤다면 멈추고 휴식을 취하십시오. 해결 방법은 컴퓨터를 종료한 지 5분 후, 점심을 먹는 동안 또는 다음 날 아침 샤워 중에 가장 이상한 순간에 종종 나타납니다.

결론: 오래된 프로그래머를 목장에 내버려두지 마십시오

저는 노년 프로그래머들에게 소프트웨어 산업으로 돌아가도록 격려하고 싶습니다. 여러분 중 더 많을 것으로 예상합니다. 내가 한 것처럼 당신의 기술 중 일부는 관련성이 있다는 것을 알게 될 것입니다. 또한 젊은 근로자에게 부족할 수 있는 직업 윤리, 조직 및 신뢰성에 대한 소프트 스킬이 있습니다. 유연한 일정으로 집에서 일할 수 있는 기회는 내가 업계를 떠날 당시 우리가 가졌던 그 어떤 것보다 뛰어났습니다. 프로그래밍을 위한 저렴한 온라인 교육 프로그램이 전례 없이 급증했습니다.

계속 지켜봐! 나는 DevSlopes를 통해 작업하고 풀 스택 웹 개발자로 자신을 리브랜딩함에 따라 이것이 시리즈의 첫 번째가 될 것으로 기대합니다.

https://www.itworld.co.kr/numbers/82001/272637

https://programmers.co.kr/pages/2022-dev-survey

개발자 커리어 플랫폼 프로그래머스 운영사 그렙이 국내 개발자들의 기술 트렌드와 커리어 고민을 엿볼 수 있는 ‘2022 프로그래머스 개발자 설문조사 리포트’를 공개했다고 밝혔다.

프로그래머스 홈페이지에 공개된 리포트는 프로그래머스를 이용하는 개발자 5,362명을 대상으로 2021년 12월 3일부터 31일간 실시된 온라인 설문조사 결과를 바탕으로 발행됐다. 개발자 설문조사 리포트는 우리나라 개발자들의 생각을 공유하는 목적으로 매년 상반기에 발행한다. 이번 리포트에는 근무 지역·형태, 평균 연소득, 자주 사용하는 툴, 배우고 싶은 프로그래밍 언어, 이직과 구직 시 중요한 점, 채용 정보와 개발 트렌드를 얻는 곳 등 총 35문항을 수록했다.
 

ⓒ 그렙
해당 자료에 따르면, 응답한 개발자 49.5%는 회사로 출근한다고 응답했다. 재택근무와 출근을 병행하는 개발자는 38.3%, 재택근무만 하는 개발자가 12.2%로 총 응답자 중 87.8%의 개발자는 회사로 출근한 것으로 나타났다. 가장 많은 개발자가 근무하는 지역은 서울시 강남구(25.3%)로 나타났으며, 네이버, 엔씨소프트 등 IT 기업이 다수 포진돼 있는 경기도 성남시(14.5%)가 2위, 강남구 옆에 위치한 서초구(6%)가 3위를 기록했다.

연소득 관련 질문에서는 설문에 참여한 개발자의 43.5% 만이 4,000만 원 이상을 받는다고 답했다. 개발자 영입 전쟁이 치열해지면서 처우개선과 사이닝 보너스, 스톡 옵션 제공이 연일 화제가 되고 있으나 모든 개발자가 고액의 연봉을 받지는 않는 것으로 나타났다. 

한편, 개발자들이 회사를 선택할 때 가장 중요하게 여기는 것은 연소득/인센티브/스톡옵션 등의 금전적 보상(60.3%)이었으며, 다음으로 동료(55.1%)와 개발 스택/환경(47.7%)을 고려한다고 답했다. 개발자들이 선택한 회사를 선택하는 기준 톱3는 매년 변하지 않는 순위를 유지하고 있다.

개발자들이 가장 자주 사용하는 에디터(최대 2개 선택)는 비주얼 스튜디오 코드(56.3%), 인텔리J(29.6%), 이클립스(17.7%) 순이었다. 비주얼 스튜디오 코드는 2020년 46.5%와 비교해 10% 가까이 사용량이 증가했다. 또한 새롭게 배우고 싶거나 배울 필요성을 느끼는 언어는 코틀린(15.5%), 고(15.3%), 타입스크립트(12.5%) 순이었다. 2020년 1위를 차지한 파이썬의 경우 4위로 하락했는데, 이미 많은 개발자들이 Python에 익숙해졌기 때문인 것으로 분석했다.

또한 매일 밤샘 근무를 하는 개발자 이미지와 달리 34.7% 개발자는 야근을 하지 않는 것으로 나타났다. 매일 또는 거의 매일 높은 강도로 야근하는 개발자는 13%로 응답자 중 가장 적은 비중을 차지했다.

그렙 이확영 대표는 “해외에도 다양한 개발자 설문조사 리포트가 발행되지만 국내와 근무환경이 다르기 때문에 우리 주변의 개발자들의 생각을 보여주지는 못하는 아쉬움이 있었다”면서 “프로그래머스는 설문조사 리포트를 통해 많은 개발자들이 궁금증을 해소하고 공감대를 얻기를 바라는 마음으로 매년 상반기 설문조사 리포트를 발행하고 있다”라고 말했다.

Online Typing Practice for Programmers

https://www.speedcoder.net/

.

프로그래머에게 필요한 5가지 덕목

         

1. 모든 걸 잘 하는 게 아닌 걸 인정하자

아무리 난다 긴다 하는 프로그래머도 모든 걸 잘 할 수는 없습니다. 어떤 프로그래머도 모든걸 경험할 수 없습니다. 이걸 모두가 인정하는게 가장 중요합니다. 기획자와 프로그래머 사이에 미묘한 긴장감이 흐르면 기획자는 “내가 만든 기획들은 다른 회사에서 이미 했던거야, 그러니 너는 나에게 반박할 수 없을 걸?”이라는 생각을 가지고 접근하게 됩니다.

가끔 프로그래머에게 와서 이거 되냐고 묻죠. 된다고 얘기하면 그 때 된다고 하지 않았냐며 기획에 넣었다 그러죠. 그런데, 된다. 한다. 할 것이다. 이게 다 같은 얘긴가요? 아닙니다. 이런 문제가 일어나는 이유는 팀웍에 문제가 있기 때문입니다. 그래서 인정해야 합니다. 너와 나, 우리 모두 모든 걸 잘하는 게 아님을.

 

2. 자존심을 세우는 건 좋지만, 쓸데 없는 자존심은 버리자

프로그래머들의 성향은 자존심이 센 경우가 많습니다. 전문직종 사람들이 다들 그렇죠. 이는 본인이 하는 일에 대한 프라이드이기도 하고 자신의 두뇌에 대한 프라이드이기도 한데, 그렇게 나쁜 것만은 아닙니다. 프라이드가 적은 사람은 그만큼 책임감도 적기 때문입니다.

하지만, 내가 해본 것과 해보지 않은 것, 할 수 있는 것과 할 수 없는 것, 빨리 할 수 있는 것과 빨리 할 수 없는 것은 냉철하게 판단해야 합니다. 그래서 “난 이 기간 동안 이걸 만들 수 없다.”고 말할 수 있어야 합니다.

 

3. 기획단계부터 참여하자

이 말을 잘 이해해야 합니다. 기획에 감 놔라, 배 놔라 하라는게 아닙니다. 기획단계에서부터 서로 대화를 하라는 겁니다. 무엇을 만들기로 했으면 어떻게 해야 쉽고 빠르게 만들수 있는지 서로 대화를 해서 내가 선택한것처럼 기획자가 선택할수 있게 되면 더할나위 없이 좋겠죠. 이는 서로에게 좋은 기회일 겁니다.

 

4. 폭넓은 지식을 쌓자

프로그래머가 너무 기술만 파면 다른 파트와 대화가 안 됩니다. 폭넓은 지식을 쌓을수 있도록 노력해야 됩니다. 그래야 기획도 할 수 있고, 기획자랑 대화도 할 수 있고, 나중에는 사업도 할 수 있습니다.

 

5. 같은 프로그래머끼리 괴롭히지 말자

“내가 만들면 3일이면 되는데 저거 만드는데 뭐 이렇게 오래걸려?” 이런 말을 입에 달고 사는 사람들이 있습니다. 어떤 미국에 좋은 학교를 나온친구가 자기가 하면 일주일이면 된다고 했습니다. 그래서 그 사람에게 일을 시켰죠. 그런데 못했어요. 한 달 넘게 걸렸을 겁니다. 그 친구가 프로그래밍 실력이 없어서 못한건 아니에요. 상대 업체가 메뉴얼을 줬는데 준데로 만들어도 안됐거든요.

모든일이 각자 다 사정이 있습니다. 위와 같은 말은 절대 해선 안됩니다.

 

 

보너스, 기획자에게 부탁하고 싶은 말

 

1. 막 던지지 말자

300명이 참여한 프로젝트와 비교하지 마세요. 특히… “엑셀처럼 만들어 주세요”, “포토샵은 되던데”, “네이트온에 있는 기능은 다 있으면 됩니다”

… 이런 말은 일진 애들이 빵셔틀한테 500원 주고 2만원 어치 사온 다음 거스름돈 가져와라는 말과 같습니다.

 

2. 프로그래머의 개인 취향과 특성을 존중하자

저는 게임회사를 다니고 있습니다. 제가 본 바로는, 아티스트들에 대해서는 취향과 경험을 존중해 줍니다. 물론 경영진 앞에서는 이런 것들이 무시되기 십상이기 때문에 나름의 고충이 있지요. 그런데 프로그래머는 더 심합니다. 프로그래머들의 장단점, 취향 따위는 아예 고려가 되지 않습니다.

기획자는 다른 회사의 제품을 벤치마킹을 해서 기획을 합니다. 그리고 프로그래머에게 기획서를 주죠. 그럼 프로그래머는 연구도 하고 삽질도 하면서 프로젝트를 진행시킵니다. 당연히 야근은 필수고 과정 자체도 만족스럽지 못하며 프로그램을 완성시켜도 질이 좋지 않습니다.

 

3. 프로그래머는 시다바리가 아닙니다

우리나라는 서비스 기획자가 최고입니다. 이 나라에 있는 대부분의 회사가 그렇게 생겼습니다. 하지만 해외에서는 프로그래머가 주도하는 회사도 많습니다. 글로벌 기업의 경우에는 더욱 그렇고요. 건축현장에서도 설계자와 현장에서 일하시는분과의 마찰이 있고, 의상디자이너와 현장직 아주머니와의 마찰이 있습니다. 그래도 이 분들은 다들 전공이 그쪽입니다. 반면 소프트웨어, 웹 기획자는 전산 전공이 아니죠.

때문에 디테일한 부분에서 프로그래머가 더 많이 아는 영역이 많습니다. 많은 기획자 분들이 따라오려 노력하지만, 그 차이는 쉽지 않습니다. 그렇다면 당연히 프로그래머를 파트너로 대해야겠지요?

 

원문: 모영철 프로그램 철학 / 편집: 리승환

http://wiki.kldp.org/wiki.php/HowToBeAProgrammer#s-3.2.1

목차

Contents

1 도입

2 초보자

2.1 개인적 기능들

2.1.1 디버그 배우기

2.1.2 문제 공간을 나눠서 디버그 하는 방법

2.1.3 오류를 제거하는 방법

2.1.4 로그를 이용해서 디버그 하는 방법

2.1.5 성능 문제를 이해하는 방법

2.1.6 성능 문제를 해결하는 방법

2.1.7 반복문을 최적화하는 방법

2.1.8 I/O 비용을 다루는 방법

2.1.9 메모리를 관리하는 방법

2.1.10 가끔씩 생기는 버그를 다루는 방법

2.1.11 설계 기능을 익히는 방법

2.1.12 실험을 수행하는 방법

2.2 팀의 기능들

2.2.1 시간 추정이 중요한 이유

2.2.2 프로그래밍 시간을 추정하는 방법

2.2.3 정보를 찾는 방법

2.2.4 사람들을 정보의 원천으로 활용하는 방법

2.2.5 현명하게 문서화하는 방법

2.2.6 형편없는 코드를 가지고 작업하기

2.2.7 소스 코드 제어 시스템을 이용하는 방법

2.2.8 단위별 검사를 하는 방법

2.2.9 막힐 때는 잠깐 쉬어라

2.2.10 집에 갈 시간을 인지하는 방법

2.2.11 까다로운 사람들과 상대하는 방법

3 중급자

3.1 개인적 기능들

3.1.1 의욕을 계속 유지하는 방법

3.1.2 널리 신뢰받는 방법

3.1.3 시간과 공간 사이에서 균형을 잡는 방법

3.1.4 압박 검사를 하는 방법

3.1.5 간결성과 추상성의 균형을 잡는 방법

3.1.6 새로운 기능을 배우는 방법

3.1.7 타자 연습

3.1.8 통합 검사를 하는 방법

3.1.9 의사소통을 위한 용어들

3.2 팀의 기능들

3.2.1 개발 시간을 관리하는 방법

3.2.2 타사 소프트웨어의 위험 부담을 관리하는 방법

3.2.3 컨설턴트를 관리하는 방법

3.2.4 딱 적당하게 회의하는 방법

3.2.5 무리 없이 정직하게 반대 의견을 내는 방법

3.3 판단 능력

3.3.1 개발 시간에 맞춰 품질을 조절하는 방법

3.3.2 소프트웨어 시스템의 의존성을 관리하는 방법

3.3.3 소프트웨어의 완성도를 판단하는 방법

3.3.4 구입과 개발 사이에서 결정하는 방법

3.3.5 전문가로 성장하는 방법

3.3.6 면접 대상자를 평가하는 방법

3.3.7 화려한 전산 과학을 적용할 때를 아는 방법

3.3.8 비기술자들과 이야기하는 방법

4 상급자

4.1 기술적 판단 능력

4.1.1 어려운 것과 불가능한 것을 구분하는 방법

4.1.2 내장 언어를 활용하는 방법

4.1.3 언어의 선택

4.2 현명하게 타협하기

4.2.1 작업 일정의 압박과 싸우는 방법

4.2.2 사용자를 이해하는 방법

4.2.3 진급하는 방법

4.3 팀을 위해 일하기

4.3.1 재능을 개발하는 방법

4.3.2 일할 과제를 선택하는 방법

4.3.3 팀 동료들이 최대한 능력을 발휘하게 하는 방법

4.3.4 문제를 나누는 방법

4.3.5 따분한 과제를 다루는 방법

4.3.6 프로젝트를 위한 지원을 얻는 방법

4.3.7 시스템이 자라게 하는 방법

4.3.8 대화를 잘 하는 방법

4.3.9 사람들에게 듣고 싶어 하지 않는 말을 하는 방법

4.3.10 관리상의 신화들을 다루는 방법

4.3.11 조직의 일시적 혼돈 상태를 다루는 방법

5 참고 문헌

5.1 책

5.2 웹 사이트

6 역사 (2003년 5월 현재) / History (As Of May, 2003)

6.1 피드백 및 확장 요청 / Request for Feedback or Extension

6.2 원본 / Original Version

6.3 원저자의 경력 / Original Author's Bio

"프로그래머가 되고 싶은데 수학을 못해요"라는 질문에 대한 답...

제가 수학성적을 60점에서 100점으로 올린방법은 아래 링크에 있습니다.
http://kblog.popekim.com/2012/05/60-1...