최하위 경쟁에서 프로그래밍은 직업입니까? [닫은]

프로그래밍 업계가 바닥에 서있는 것처럼 보입니다. 우리가 다음의 관행을 취하는 경우 :

1. 모범 사례를 구현하는 데 시간이 걸리지 않음
2. 타인의 사람 코드를 가능한 많이 사용 (책임에 따른 사용자 지정 코드)
3. 점점 더 높은 수준의 언어를 사용하여 생산성 향상
4. "프로그래밍"을 크게 단순화하고 사람들이 코드 뒤의 배관을 이해할 필요가없는 GUI 기반 개발 "도구"

이것들은 우리가 다른 회사원처럼되기 위해 경쟁하고 있다는 것을 의미합니다. 기술을 필요로하지 않는 것 (대체하기 쉬운 것), 사전 제작 된 것 (프로젝트 시간 단축)이 고용주의 이익에 달려 있습니다.

여기서 요점은 a) 사용자의 기술과 경제적 이익 사이에 불일치가 있는가? 그리고 b) 있다면, 전문적인 표준을 시행하기 위해 어떻게 완화합니까?

나는 당신이 매우 신랄한 질문을 한 것 같습니다.

GUI 코딩 도구를 만들면 로봇이 조립 라인 작업자를 작업에서 제외시키는 것처럼 프로그래머가 작업에서 벗어날 수 있습니다. 제 생각에 일자리가 줄어든 반면 다음 일자리의 위치도 바뀌고 있습니다.

과제를 완수하는 기술은 바뀌지 만 과제는 여전히 완료되어야합니다. 응용 프로그램이 작동하려면 코드 / 비즈니스 로직을 여전히 조합해야합니다.

기술의 변화는 프로그래머에게 선택의 폭을 넓 힙니다. GUI 기반 프로그래밍 또는 프로그램 GUI 도구를 배우십시오.

직원의 기술과 고용주의 이익 사이에 오정렬이있을 수 있지만, 특히 고용주가 정통한 경우에는 오래 걸리지 않습니다. 따라서 상호 이익을 위해 무엇을 추구하는 것이 고용주와 직원 모두에게 최선의 이익입니다. 그러나 하나는 필연적으로 다른 것보다 앞설 것입니다. 잘하면 그것은 당신입니다 (-:

최고의 소원,

KM

언급 한 트렌드에 IMHO가 설명하는 것을 하나 더 추가합니다.

그 어느 때보 다 훨씬 더 많은 프로그래머가 필요합니다.

프로그래밍을 필요로하거나 포함하는 작업의 양은 계속 증가하고 있으며 프로그래머 수보다 훨씬 빠릅니다. 오늘날에는 보통 자동차에 여러 개의 마이크로 칩이 있습니다. 5 년 안에 냉장고와 토스터에 칩이있을 수 있습니다. 10 년 후, 당신의 속옷은? 그리고 누군가는 이러한 작업을하기 위해 모든 소프트웨어를 생산해야합니다. 따라서 자동화 가능한 모든 것을 자동화하고 "생산성"을 향상시키기 위해 가능한 모든 노력이 있습니다 (그러나 정의 된대로). 그리고 점점 더 신선한 두뇌가 모집됩니다.

이것은 오늘날의 활동적인 프로그래머의 대부분이 경험이 부족하고 /하거나 자신의 직업을 준비하지 못했음을 의미합니다. 적절한 수준의 경험을 얻는 데 몇 년이 걸리며, 그곳에 머 무르려면 지속적인 학습이 필요합니다. 결론 은 점점 더 많은 프로그래밍 작업이 점점 더 어려워지고 있다는 것입니다. 그러나 그들을 찾고있는 사람에게는 여전히 충분한 도전이 있습니다 .

위의 요점에 대해 악마의 옹호자를 연주하겠습니다.

모범 사례를 구현하는 데 시간이 걸리지 않음

많은 사람들은 그렇지 않습니다. 많은 사람들은 그렇지 않습니다. 몇 년 전 처음으로 단위 테스트와 민첩한 접근 방식을 발견했을 때 동료 중 누구도 그것이 무엇인지 조금도 알지 못했습니다. 오늘날에는 대학에서 거의 표준 자료이므로 많은 신입생들이 이미 그것을 이해하고 있습니다.

타인의 사람 코드를 가능한 많이 사용 (책임에 따른 사용자 지정 코드)

무엇과 반대로? 바퀴를 재발견? 아니면 그것을 피하기 위해 다른 사람들의 코드를 사용합니까?

문제를 해결하기 위해 (대부분) 비용을 지불하고 코드 작성이 끝이 아니라 수단이라는 점에 주목하는 것이 중요하다고 생각합니다 . 한 줄의 코드를 작성하지 않고 문제를 해결할 수 있으면 여전히 클라이언트를 만족시킵니다. 특히 이런 식으로 우리는보다 안정적인 솔루션을 더 빠르고 저렴하게 생산할 수 있습니다. 나는 그것에 아무런 문제가 보이지 않습니다.

점점 더 높은 수준의 언어를 사용하여 생산성 향상

어셈블리의 모든 것을 코딩하는 것과 반대로? ;-)

"프로그래밍"을 크게 단순화하고 사람들이 코드 뒤의 배관을 이해할 필요가없는 GUI 기반 개발 "도구"

어떤 도구라도 잘못 사용할 수 있습니다. GUI 빌더가 반드시 완벽하거나 우수 했음은 말할 것도없고 대부분의 (또는 적어도 일부) 제한 범위 내에서 사용할 수 있습니다. 그러나 누군가 그 한계를 모른다면 도구 나 사용자의 문제입니까?

일반적으로 펀치 카드와 기계 코드 시대에 기존 코드와 거의 동일한 비율이 현재와 같이 끔찍한 것으로 생각합니다 (증명 할 증거는 없지만)

• 전체 코드 양
• 외부인이 그러한 코드를 볼 가능성

훨씬 덜했다.

이제 인터넷과 Daily WTF를 통해 매일 최악의 예에 노출됩니다. 그것은 테러와 지진에 대한 모든 뉴스를보고 유명인과 이혼하고이 세상이 얼마나 위험하고 부도덕한지를 외치는 것과 같습니다.

상황을 올바르게 요약하지만 의미를 완전히 잘못 해석합니다.

소프트웨어가 더욱 강력 해짐에 따라 소프트웨어의 규모가 커집니다. 따라서 현재 Access를 사용할 수있을 때 전화 연락처 데이터베이스를 만드는 데 데이터베이스 프로그래머가 필요하지 않을 수도 있습니다. 워드 프레스로 갈 때 블로그를 설정하기 위해 웹 프로그래머 일 필요는 없습니다. 그러나 15 년 전에는 그러한 일을하기 위해 프로그래머가되어야하지만, 프로그래머가 지금하는 것은 15 년 전에 할 수있는 것보다 훨씬 더 많습니다.

지금부터 100 년이 지난 지금, 페이스 북이나 구글처럼 복잡한 시스템을 설정하는 것은 쉽지 않을 것입니다. 나는 그들의 웹 페이지를 말하는 것이 아니라 데이터 센터를 의미합니다. 누구나 할 수 있습니다. 우리가 여전히 전화를 사용한다고 가정하면 전화에 내장 될 것입니다. 그러나 프로그래머는 여전히 존재할 것이며, 100 년이 지난 지금부터는 '사소한'시스템에서 작업하지 않을 수도 있지만, 훨씬 더 복잡하고 정교한 시스템에서 작업 할 것입니다. 규모. 그리고 프로그래머와 같은 일부 사람들 은 그 시대의 기술을 극도로 추진하는 것을 전문 으로 선택 했기 때문에 현재의 시스템과 같은 시스템은 일반 사무 직원의 손이 닿지 않을 것 입니다.

나는 40 년 동안 그런 종류의 것을 읽었고, 나는 예측의 시작에 있지 않았습니다. 아직 일어나지 않았습니다.

COBOL은 비즈니스 프로그래머의 필요성을 없애기위한 원래 개발 도구였으며 어셈블러보다 훨씬 높은 수준의 언어였습니다. 코드 라이브러리 (자신의 코드를 작성하지 않아도 됨)는 비슷한 유물입니다.

종종 프로그래머가 아닌 사람들이 프로그래밍 작업과 비슷한 것을 할 수있는 무언가가 생깁니다. 1980 년대 "4 세대 언어", Excel과 같은 멋진 스프레드 시트, 보고서 생성기 등이있었습니다. 그들이 성공했을 때, 그들이 균일하게 행한 것은 프로그래밍에서 scutwork의 일부를 제거하고 프로그래머가 다른 더 흥미로운 것들을 할 수있게하는 것입니다.

이 패턴은 영원하지는 않지만 프로그래밍이 실제로 내리막 길임을 확신시키기 위해서는 이론적 인 주장과 예측 이상의 것이 필요합니다.

COBOL에서 최신 개발 도구로의 문제는 정확하지 않은 사양을 가져 와서 정확하고 유용한 것으로 바꾸는 기능을 대체하지 않는다는 것입니다. 이것이 프로그래머의 근본적인 능력이며 우리가 오랫동안 떠나지 않는 이유입니다.

어셈블리 및 FORTRAN 프로그래머는 구조화 된 프로그래밍과 광범위한 인터프리터가 등장 할 때 동일한 내용을 언급했을 것입니다.

하루가 끝날 무렵 소프트웨어는 이전에 수작업으로 수행했던 작업을 자동화하기위한 것입니다. 온건 한 회사의 회계 부서는 이전에 수십 명의 사람들을 필요로했을 것입니다. 이제 모든 업무를 한두 명의 업무로 수행 할 수 있습니다. 결과적으로 목표 게시물이 이동했으며 이제 회계사로부터 추가 기능 표준을 기대합니다.

Pixar는 이전보다 영화를 렌더링하는 데 시간이 더 걸립니다. 컴퓨팅 속도가 엄청나게 증가 함에도 불구하고 애니메이터는 장면의 복잡성과 세부 사항을 계속 증가시켜야했습니다. 토이 스토리 구경 애니메이션은 1995 년처럼 2010 년에는 허용되지 않습니다. 도구가 발전함에 따라 기능과 기대치도 높아졌습니다.

드래그 앤 드롭 또는 다른 프로그래밍 방법이 일반적 일 때, 세상은 더욱 도전적이고 복잡한 문제에 대한 솔루션을 요구할 것이며, 새로운 고급 도구를 사용하여이를 해결하기 위해 프로그래머가 필요합니다. 목표 게시물이 이동합니다.

아직해야 할 일이 여전히 많다는 점을 지적하는 대부분의 답변에 동의하지만, 귀하가 고려할 다른 답변을 드릴 것입니다.

예, 그렇습니다.

다른 사람들이 할 수없는 문제에 대한 해결책을 설계하려고 여기 있습니다. 툴셋에서 문제를 해결하는 데 시간을 들여 설계를 구현하는 방법에 대한 모든 작은 세부 사항을 처리하는 것은 낭비입니다.

더 높은 수준의 언어 또는 더 간단하고 더 추상적 인 도구로가는 것을 두려워하는 유일한 이유는 이러한 도구가 종종 내 가정에 따라 가정을하고 원하는 구현을 얻기 위해 가정을 해결하는 데 시간이 걸리기 때문입니다.

좋은 문제 해결사보다 항상 해결해야 할 문제가 더 많습니다. 전체 개발 체인이 단순 해져서 미취학 아동이 사용할 수있는 경우에도 대부분의 사람들은 모든 최첨단 문제에 대한 올바른 해결책을 찾지 못하기 때문에 사람들이 더 나은 솔루션에 대한 비용을 지불 할만큼 충분하지 않거나 비효율적 인 솔루션을 사용할 수 있습니다. 그리고 좋은 솔루션을 만들기 위해 고려해야 할 가정.

우리의 직업은 대부분의 다른 것보다 문제를 더 잘 해결하는 것입니다. 툴체인의 복잡성은 큰 그림에서 크게 벗어나지 않는 한 큰 그림보기와 관련이 없습니다.

프로그래밍 기술이 변경 될 수 있지만 소프트웨어 제품의 근본적인 복잡성은 여전히 ​​존재합니다. 다이어그램이나 순서도 (또는 다른 '간단한'방법)를 사용하여 소프트웨어를 완전히 작성할 수있는 경우에도 소프트웨어의 모든 복잡성을 이해하고 해결해야합니다. 따라서 고용주가 회사의 제품을 알고있는 프로그래머가 제품을 업데이트하거나 새로운 기능을 추가 할 수 있도록하는 것이 중요합니다. 직원이 소프트웨어 제품을 배우는 데 꽤 시간이 걸릴 수 있습니다.

대부분의 패키지 소프트웨어는 선반을 자동화하거나 분리 할 수있는 두 가지 범주로 나뉩니다.

1. 사용하기 간단하지만 비즈니스에 실제로 필요한 것과는 일치하지 않습니다
2. 커스터마이징이 가능하지만 커스터마이제이션을 이해하고 활용하려면 전문가가 필요합니다.

세 번째는 잊어 버린 것 같습니다. 표준 생산성 소프트웨어 (이메일, 브라우저, 워드 프로세서 등)입니다. 범주 1의 소프트웨어는 소프트웨어 개발자를 고용하여 비즈니스 소프트웨어를 사용자 정의 할 수 있도록합니다 (가능한 경우). 내부 및 외부의 사용자 정의 가능한 시스템이 SAP, PeopleSoft 등을 염두에두고 있거나 죽어가는 종족 (SAP 및 PeopleSoft와 유사한 시스템을 생각하지 않기 때문에)을 알고있는 사람은 개발자를 고용 할 수도 있습니다. 동일한 시장 침투율을 보임).

개발자가 항상 필요합니다. 내가보고있는 것은 수동적이고 지루하고 반복적 인 작업이 더 많이 자동화되었다는 것입니다 (수동으로 데이터 액세스를위한 코드 작성과 O / RM 사용). 이를 통해 개발자는 적은 노력으로 비즈니스에 더 많은 가치를 제공 할 수 있습니다.

나는 당신의 주장을 받아들이지 않습니다 :

1. 모범 사례를 구현하는 데 시간이 걸리지 않음

그거 빼고

1. 타인의 사람 코드를 가능한 많이 사용 (책임에 따른 사용자 지정 코드)

코드 재사용이 가장 좋습니다. 사용 된 코드가 테스트됩니다. 물론 많은 사람들이 관리하고 사용하는 좋은 소스의 코드를 사용해야합니다.

1. 점점 더 높은 수준의 언어를 사용하여 생산성 향상

생산성 자체는 나쁘지 않습니다. 그렇지 않습니까?

1. "프로그래밍"을 크게 단순화하고 사람들이 코드 뒤의 배관을 이해할 필요가없는 GUI 기반 개발 "도구"

도구가 작업을 수행하는 경우 : 도구를 사용하십시오. 그렇지 않은 경우 : 거부하십시오. 약속이 지키고 사람들이 실제로 코드를 이해할 필요가 없다면 잘되었습니다! 이것이 약속이 아니라고 말하는 것 같습니까?

(여기의 숫자는 자동으로 잘못 렌더링됩니다. :))

비주얼 프로그래밍은 텍스트 기반 프로그래밍보다 타당하거나 유효하지 않습니다.

시각적으로 프로그래밍 할 때 특정 결점과 과제가 있지만 무시할 때 잠재적으로 위험한 기본 구성 요소 배관은 시각적 구성 요소와보다 관련성이 높은 시각적 디자이너가 독점하지 않습니다. 기본 배관을 무시하면 모든 개발에 위험이 있습니다.

Labview를 이용할 수있는 기회가 있다면 가능성 (또는 레고 NXT 환경의 특수 변형)을 볼 수 있습니다. 결함이나 단점이없는 것은 아니지만 상속 혜택이 있습니다. 보는 것은 믿는 것입니다.

프로그래밍 관행은 생산성을 높이고 특정 유형의 개발 (최종)에 대한 비용을 절감 할뿐만 아니라 응용 프로그램 기능과 고객 기대를 증가시킵니다 (최상위 경쟁을 장려). Goole과 Facebook이 최고 기술자를 얻기 위해 지불하는 보너스를 확인하십시오.

프로그래밍만큼이나 변화를 추구하는 존재 공학을 다루는 다른 직업은 없습니다. 무언가를 단순화하자마자 새로운 아이디어를 낳는 새로운 문제에 대한 캔을 열면됩니다.

따라서 다른 개인의 노력으로 인해 코드와 솔루션을 공유하여 개인 개업의 나쁜 관행, 나쁜 습관 및 인본주의가없는 방식으로 새로운 도전, 아이디어 및 사용자 경험으로 이동하는 데 도움이됩니다.

우리가 다음의 관행을 취하는 경우 :

이런 씨발? 이 목록이 일치하지 않습니까? 목록은 경고없이 앞뒤로 전환하지 않고 각 요소에 대해 같은 쪽에서 가져와야합니다. 따라서 목록은 다음과 같아야합니다.

우리가 다음의 관행을 취하는 경우 :