취소
다음에 대한 결과 표시 
다음에 대한 검색 
다음을 의미합니까? 

제목:

왜 업데이트가 느린가에 대해..

(게시글 작성 시간: 02-04-2021 06:29 PM)
1320 보기
Anonymous
해당 사항 없음
옵션
갤럭시 S
가끔 보다보면 소프트웨어 업데이트가 느리다고 불만을 가지시는 분들이 있습니다.
그리고 대부분의 사람들이 그 책임을 전부 개발자 탓으로 생각하는데

그래서 현직으로 개발자들과 같이 작업을 하게 된 한 웹 디벨로퍼 분이 쓴 글을 스크랩했습니다.
Adrian opera라는 분이 쓰셨습니다.

제가 말하고자 하는 건
삼성을 쉴드치는게 아닌
어느 핸드폰 제조사든 개발자가 느린 소프트웨어 업데이트에 대한 이유가 아니란 겁니다.

본문과 파파고로 간단히 번역한 글입니다.
짧으면 제가 직접 번역하겠지만 너무 길어서....

저격글도 아니고 느린 소프트웨어에 대해 불만갖지 말란 것도 아닙니다.
느리면 느린거고 욕먹을 수밖에 없고 불매를 하면 됩니다.
다만 책임을 엉뚱한 곳에 물으면 안된다는 겁니다.

So here’s the deal. I started listening to some podcasts related to content marketing and social media, since I want to up my game a bit.
One of the things that bothered me the most is the continuous bickering of the podcast hosts about how they avoid to go to developers because it always takes a lot of time to get stuff done with devs. So I thought I would write an article detailing the struggles of developers when they get “work” that’s supposed to be ready yesterday.
To set the stage, let me first tell you what developers are not.
Developers are not code monkeys. Software development is not just the practice of writing code that is known a priori to solve a problem and you only need to be a monkey with a very good memory and remember a lot of **bleep**, so that you can type it into a computer and make a button green.
A whole different skill set is needed when trying to make a button green, than it is to figure out the interactions for that button and use gradients instead of solid colors to implement the “requirement”. And this is only the frontend. Forget about form validations, sequencing those validators properly, replicating on the backend, saving to a DB.
Well, you could say that work is meant to be hard and that I shouldn’t complain. I’m not. That’s my opinion, too. And I also believe that work is as hard on you as you allow it to be.
People assume developers are these lazy dudes and dudettes who hide behind the complexity of the technologies they use to justify why things are taking longer than everyone expects. And that they tend to over-complicate things so that they become indispensable to the project.
That’s communist mentality on both ends — a business owner thinking that devs are like that, or a developer actually behaving like that.
Yes, developers **bleep** at setting expectations, but that’s mostly because we’re always pressured to give an estimate (a very short/small one, that is) and then jump directly to work.
You should understand that planning is not something reserved for the upper tier in the company. It’s not something that’s only used so that your plans as a business match your expectations as business people.
Developers also plan their work. In fact, I like the teams I work with more, if they spend an equal amount of time planning vs. doing.
Why? Because they will have more data and would have already explored more options to make more informed decisions. I also like people who can defer decisions for as long as possible. It’s always better to make decisions with the most amount of data you can get your hands on.
So what’s the problem, then?
Well, part of it is that you have a **bleep** culture. It’s you not having planning and feedback as core values/practices within your organization.
A software project / feature request usually starts like this: business asks for some unfeasible, ludicrous **bleep**, they probably heard about at one of their fine dinners with competitors or partners with teams 10x larger. Next, you ask for an estimate but also mention a deadline tht doesn’t take into account the fact that you have resources blocked on other projects, the context-switching involved and other sensitive and less-obvious things. Next, developers offer a dumb estimate just to please you and then try to put square pegs in round holes.
3 months pass without communication and feedback on both ends. Developers grow more frustrated as they realize the deadline is approaching and they can’t deliver on the promise, you also become frustrated because it took 3 months for you to get a **bleep** feature out and the market is already becoming crowded with similar features from competitors…
After an extra more month of testing, improvement and “stabilization” of the feature (we all know that means rewriting the crap devs initially wrote), it becomes irrelevant to the business and you decide to drop it. This builds up even more frustration since devs now think you are disrespecting their work. Without proper communication from you from start to finish, they will just think you’re treating them as shovel-handlers.
If you’re a developer, you might ask if this could be avoided. Yes, it totally could be!! Just talk! Speak out about it. I don’t care that your boss is some knucklehead and sometimes is intimidating. Tell them they’re wrong.
There’s a catch, though. You need to tell them they’re wrong but also offer alternatives. Give them options, guide them.
As the business owner or the person asking for the feature, treat your tech people as the professionals they are, get feedback from them and process it accordingly. They’re not providing proper feedback? Maybe you will have to teach them that. Maybe you will have to make your expectations more obvious.
The first thing I try to do when my team starts doing weird stuff I don’t agree with is I try to talk more, give them more information into what I’m thinking, offer them more context so that they can make more informed decisions. I always assume I was ignorant and I expected them to know something that was clear in my head.
I recently had a feature request from the client, on a project I’m working on, that drove me bonkers.
The client wanted us to implement a special excel export feature on the admin panel, then use that excel in a feature that would parse the file, import the accounts back, then trigger an application workflow on it, that was also automatically handled by a Cron job.
I kept acting dumb and asking “Why?”. “Why do we need this?” , “What are you going to do with this?”. I drove them crazy. I looked like I didn’t know anything about software development, I was the dumbest person in the room.
Want to know the outcome? Do you know what they needed?
A **bleep** button to manually trigger that workflow managed by the Cron job! On all the registered users of the website, excluding the ones already processed automatically by the Cron job.
A… **bleep**… button!!
The moment I understood what they wanted and they understood what they needed, I replayed everything that could go wrong with their initial reqruiement, in my head, in a loop.
Us starting development on this monster just to be able to manually trigger the functionality. Something we can easily do using a button and some custom code. All that XML parsing and validating … I was ready to tear my hair off my head, but fortunately, the many years of being a father and a software developer helped me by ridding me of my hair.
To conclude, you need planning on all ends. Business, content, development.
You need a higher goal that all plans converge towards. If you want to drive in more sales, marketing wants to create a more meaningful brand and development is focused on improving the tech stack, all your efforts will burn down in flames.
You need to make work visible and priorities obvious — use a **bleep** Kanban board! Stop usig Scrum just because you heard everyone is using it. From my experience, everyone is using int WRONG!
You need to empower people to say “No”. And take their answer as being the correct one, since they are the professionals. Don’t be like our dearly departed Ceausescu and assume that if you’re the manager of all people you also know more than they do. If they dug a tunnel on one end, trust that their judgement is sound. Challenge their decisions at every step, so that they’re able to reflect properly, but don’t ask for explicit changes, let them do course correction.
As a member of the development team, you need to know that business is not just a bunch of money-loving monkeys. They’re professionals who want to keep the business afloat and keep money coming in so you can get paid. They might also have an interest in keeping the prestige of the company, upping the service level standards.
You need to inform those people on the decisions you make on your end and make sure your decisions align with their goals. Try to talk in their language, they don’t necessarily understand your amazing caching systems and load-balancer gymnastics. But they do understand you want to save time and resource usage by storing the data somewhere closer, in a form that the application already understands. They will understand that you’re trying to offer a better user experience by trimming down the number of fields a user has to fill in to use a specific feature.
And don’t think marketing is a bunch of social media monkeys just posting to Facebook day-in and day-out. There’s a lot of strategy and planning that goes into this posting part. Creating an ad could take 1 week because they have to make sure the headline is effective. And this doesn’t take into account that they have to write compelling body copy and also choose an image that draws the eye.
Keep an open mind!

자, 이렇게 합시다. 나는 내 게임을 조금 더 발전시키고 싶기 때문에 컨텐츠 마케팅과 소셜 미디어와 관련된 팟캐스트를 듣기 시작했다.
나를 가장 괴롭혔던 것 중 하나는 팟캐스트 호스트들이 개발자들에게 가는 것을 피하는 방법에 대해 끊임없이 다투는 것이다. 왜냐하면 개발자들은 개발자들과 일을 하는데 항상 많은 시간이 필요하기 때문이다. 그래서 어제 준비하기로 되어 있는 '일'을 받을 때 개발자들의 고군분투가 상세히 기술된 기사를 써야겠다고 생각했다.
무대를 꾸미기 위해서는 먼저 개발자가 아닌 것을 알려줄게.
개발자들은 코드 원숭이가 아니다. 소프트웨어 개발은 단순히 문제를 해결하기 위해 선험적으로 알려진 코드를 쓰는 관행이 아니며, 기억력이 아주 좋은 원숭이가 되어 똥을 많이 기억하기만 하면 되므로 컴퓨터에 입력하여 단추를 녹색으로 만들 수 있다.
버튼을 녹색으로 만들려면 버튼의 상호작용을 파악하고 "필수"를 구현하기 위해 견고한 색상 대신 구배를 사용하는 것과 완전히 다른 기술이 필요하다. 그리고 이것은 단지 앞부분일 뿐이다. 양식 검증, 검증자 시퀀싱, 백엔드 복제, DB에 저장 등은 잊어버리십시오.
글쎄, 너는 일은 힘들어야 하고 내가 불평하지 말아야 한다고 말할 수 있을 것이다. 난 아니야. 그것도 내 의견이다. 그리고 나는 또한 일이 당신이 허락하는 것만큼 당신에게 힘들다고 믿는다.
사람들은 개발자들이 왜 모든 사람들이 기대하는 것보다 시간이 오래 걸리는지 정당화하기 위해 사용하는 기술의 복잡성 뒤에 숨어있는 게으른 인간들과 인간이라고 추측한다. 그리고 그들은 그 프로젝트에 없어서는 안 될 것이 되기 위해 지나치게 일을 처리하는 경향이 있다.
그것은 양쪽 끝의 공산주의 사고방식이다. 즉, 개발업자가 개발업자가 실제로 그렇게 행동한다고 생각하는 것이다.
그래, 개발자들은 기대치를 정하는 데는 서툴지만, 그것은 대부분 우리가 항상 견적(아주 짧은/작은 것, 즉)을 주고 나서 바로 직장으로 뛰어오라는 압력을 받기 때문이다.
당신은 회사의 고위층을 위한 계획이 아니라는 것을 이해해야 한다. 비즈니스로서의 계획이 비즈니스맨으로서의 기대와 일치하도록만 사용되는 것은 아니다.
개발자들도 일을 계획한다. 사실, 나는 내가 함께 일하는 팀들이 계획하는 것과 같은 시간을 보내는 것을 더 좋아한다.
왜냐고? 왜냐하면 그들은 더 많은 데이터를 가지고 있고 더 많은 정보에 입각한 결정을 내릴 수 있는 더 많은 옵션을 이미 탐색했을 것이기 때문이다. 나는 또한 가능한 한 오랫동안 결정을 연기할 수 있는 사람들을 좋아한다. 손에 넣을 수 있는 가장 많은 양의 데이터를 가지고 결정을 내리는 것이 항상 더 낫다.
그럼 뭐가 문제야?
글쎄, 그 중 일부는 네가 더러운 문화를 가지고 있다는 거야. 조직 내에서 핵심 가치/실무로서 계획 및 피드백을 제공하지 않는 경우
소프트웨어 프로젝트/기능 요청은 대개 다음과 같이 시작한다. 사업은 실현 불가능하고 우스꽝스러운 것들을 요구한다. 그들은 아마도 10배 더 큰 팀을 가진 경쟁자나 파트너들과의 훌륭한 만찬 중 하나에서 들었을 것이다. 다음으로, 당신은 견적을 요구하지만 마감일을 언급하는 것은 당신이 다른 프로젝트에서 차단된 자원, 상황 교환과 관련된 다른 민감하고 덜 명백한 것들을 고려하지 않는다. 다음으로, 개발자들은 여러분을 기쁘게 하기 위해 바보 같은 견적서를 제시하고 나서 둥근 구멍에 사각형 페그를 넣으려고 노력한다.
양끝에 대한 소통과 피드백이 없는 3개월이 지났다. 개발업자들은 마감일이 다가오고 있다는 것을 깨닫고 약속을 이행할 수 없을 때 더 좌절하게 된다. 또한 당신은 빌어먹을 기능을 꺼내는데 3개월이 걸렸고 시장은 이미 경쟁업체들로부터 비슷한 기능들로 붐비고 있기 때문에 좌절하게 된다.
이 기능의 테스트, 개선 및 "안정화"를 한 달 더 한 후에(우리 모두는 처음에 쓴 쓰레기들을 다시 쓰는 것을 의미한다는 것을 알고 있다) 그것은 비즈니스와 무관하게 되고 당신은 그것을 포기하기로 결정한다. 개발자들은 이제 당신이 그들의 일을 무시하는 것이라고 생각하기 때문에 이것은 훨씬 더 많은 좌절감을 증가시킨다. 처음부터 끝까지 제대로 연락하지 않으면, 그들은 단지 당신이 그들을 삽질하는 사람으로 취급하고 있다고 생각할 것이다.
만약 당신이 개발자라면, 당신은 이것을 피할 수 있는지 물을 수 있다. 그래, 그럴 수도 있어!! 그냥 말해! 그것에 대해 솔직히 말해라. 네 상사가 얼간이고 때로는 위협적인 것은 신경 안 써. 그들이 틀렸다고 말해.
하지만, 함정이 있다. 당신은 그들에게 그들이 틀렸다고 말할 필요가 있지만 또한 대안을 제시할 필요가 있다. 그들에게 선택권을 주고, 그들을 안내해라.
비즈니스 소유자 또는 기능을 요청하는 사용자로서 기술 담당자를 전문가로 간주하고 피드백을 받아 그에 따라 처리하십시오. 제대로 된 피드백을 제공하지 않는 건가? 아마도 너는 그들에게 그것을 가르쳐야 할 것이다. 아마도 당신은 당신의 기대를 더 분명히 해야 할 것이다.
우리 팀이 이상한 일을 하기 시작할 때 내가 동의하지 않는 첫 번째 것은 나는 더 많은 이야기를 하고, 내가 생각하고 있는 것에 더 많은 정보를 주고, 그들에게 더 많은 맥락을 제공함으로써 그들이 더 많은 정보에 입각한 결정을 내릴 수 있도록 하는 것이다.
나는 항상 내가 무식하다고 생각하고 그들이 내 머릿속에 분명한 것을 알기를 기대했다.
나는 최근에 고객으로부터 내가 작업하고 있는 프로젝트에 대한 특집 요청을 받았는데, 그것은 나를 미치게 만들었다.
클라이언트는 우리가 관리자 패널에서 특별한 Excel 내보내기 기능을 실행하고, 그 탁월한 기능을 사용하여 파일을 구문 분석하여 계정을 다시 가져온 다음, Cron 작업에서 자동으로 처리되는 애플리케이션 워크플로우를 실행하기를 원했다.
나는 계속 멍청한 척하면서 "왜?"라고 물었다. "왜 이것이 필요한가?", "이걸 어떻게 할 것인가?" 내가 그들을 미치게 했다. 나는 소프트웨어 개발에 대해 아무것도 모르는 것 같았고, 나는 그 방에서 가장 멍청한 사람이었다.
결과를 알고 싶으세요? 그들에게 무엇이 필요했는지 아니?
Cron 작업에서 관리하는 워크플로를 수동으로 트리거하는 빌어먹을 버튼! Cron 작업에 의해 자동으로 처리된 웹 사이트의 모든 등록된 사용자 제외.
아... 젠장... 버튼!!
내가 그들이 원하는 것을 이해하고 그들이 필요로 하는 것을 이해하는 순간, 나는 그들의 첫 번째 재결집에 문제가 될 수 있는 모든 것을 내 머릿속에서, 순환으로 재생했다.
이 몬스터에 대한 개발을 수동으로 트리거할 수 있도록 하는 겁니다. 버튼과 사용자 지정 코드를 사용하여 우리가 쉽게 할 수 있는 것. 그 모든 XML 구문 분석과 검증... 나는 머리털을 뜯을 준비가 되어 있었지만 다행히도 아버지와 소프트웨어 개발자가 되어 여러 해 동안 나의 머리를 쥐어뜯는 것으로 나를 도왔다.
결론짓기 위해서는 모든 것을 계획할 필요가 있다. 비즈니스, 컨텐츠, 개발.
모든 계획이 하나로 모아지는 높은 목표가 필요하다. 만약 당신이 더 많은 매출을 올리고 싶다면, 마케팅은 더 의미 있는 브랜드를 만들고 싶어하고 개발은 기술 스택을 개선하는 데 초점을 맞추고 있다면, 당신의 모든 노력은 불길에 휩싸일 것이다.
일을 눈에 띄게 하고 우선순위를 분명히 해야 한다. — 빌어먹을 칸반 보드를 사용하라! 모든 사람들이 그것을 사용하고 있다는 것을 들었다고 해서 스크럼을 멈추어라. 내 경험에 따르면, 모든 사람들이 int WRONG을 사용하고 있어!
당신은 사람들이 "아니오"라고 말할 수 있도록 권한을 주어야 한다. 그리고 그들의 대답을 옳은 것으로 받아들여라, 그들은 전문가니까. 우리가 아주 많이 떠난 카이우스쿠처럼 되지 말고, 만약 당신이 모든 사람들의 관리자라면 당신도 그들보다 더 많이 알고 있다고 가정해 보라. 한쪽 끝에 터널을 뚫었다면, 그들의 판단은 타당하다고 믿어라. 모든 단계에서 그들의 결정에 도전하여, 그들이 적절하게 반영할 수 있도록 하지만, 명시적인 변경을 요구하지 말고, 그들이 과정을 수정하도록 하라.
개발팀의 일원으로서 사업은 돈만 좋아하는 원숭이 떼가 아니라는 것을 알아야 한다. 그들은 당신이 돈을 받을 수 있도록 사업을 지속시키고 돈을 계속 들어오기를 원하는 전문직 종사자들이다. 그들은 또한 서비스 수준 기준을 높여 회사의 위신을 유지하는 데 관심을 가질 수 있다.
당신은 그 사람들에게 당신이 당신의 편에서 내리는 결정에 대해 알려야 하고 당신의 결정이 그들의 목표에 맞는지 확인할 필요가 있다. 그들의 언어로 말하려고 노력하라, 그들은 반드시 당신의 놀라운 캐싱 시스템과 로드 밸런서 체조를 이해하지 못한다. 하지만 그들은 여러분이 데이터를 애플리케이션이 이미 이해하고 있는 형태로 더 가까운 곳에 저장함으로써 시간과 자원 사용량을 절약하고자 한다는 것을 이해한다. 그들은 사용자가 특정 기능을 사용하기 위해 입력해야 하는 필드 수를 줄임으로써 더 나은 사용자 환경을 제공하려고 한다는 것을 이해하게 될 것이다.
그리고 마케팅이 단지 페이스북에 매일 매일 글을 올리는 소셜 미디어 원숭이 무리라고 생각하지 말라. 이 포스팅 파트에 들어가는 전략과 계획이 많다. 광고 제작은 헤드라인이 효과적인지 확인해야 하기 때문에 1주일이 걸릴 수 있다. 그리고 이것은 그들이 매력적인 몸매를 써야 하고 또한 눈을 끄는 이미지를 선택해야 한다는 것을 고려하지 않는다.
마음을 열어라!


사실 번역본은 대충 읽어봐도 오역이 좀 많습니다. 본문을 읽으셔야 제대로 이해가 가능합니다.

감사합니다.

그리고 제게 삼빠, 삼엽충, 무지한 사람이라고 욕하지 않아주셨으면 합니다....
43 댓글
Anonymous
해당 사항 없음
갤럭시 S
긴글이지만 읽어주시기를 간곡히 부탁드립니다.
Anonymous
해당 사항 없음
갤럭시 S
컴퓨터 언어 배우는것도 힘든데
이걸 이렇게 만드냐 욕하시는분들은
다시한번 생각해볼 필요가 있을거 같습니다 ㅎㅎ
Anonymous
해당 사항 없음
갤럭시 S
저도 이쪽 분야는 아니지만 비난의 화살이 자꾸 잘못된 쪽으로 돌아가서 너무 안타깝습니다.
사실 이 문제는 화살을 쏴도 아무도 못맞추거든요... 정말 다양한 사람들이 이 프로젝트에 엮이기 때문에...
o시론o
Active Level 8
갤럭시 S
안드로이드 소프트웨어 관해서 새로운기능 추가로 넣는다 치면 그 소수값이 바뀌는대 전체적으로 바꿔줘야 적용이되기에 문제점은 다른문제가 발생할 가능성도 있습니다.. 오류,버그,호완성에서 나타나죠.ㅎ

이게다..통신사 관련 앱들때문에 더 복잡해졌고.. 한번꼬이면 찾는대 많은시간이 소요됩니다.

수정할때 빌드번호 많이바뀌는 원인이죠

앱 개발자, 스마트폰 뜻어보신분들은 이해하실겁니다.ㅎ

Anonymous
해당 사항 없음
갤럭시 S
이겁니다... 글에서도 이걸 강조하더군요. 그리고 수정될 쯤이면 타 사는 이미 그 기능을 갖추고.... 저라면 이미 속터졌을겁니다.
o시론o
Active Level 8
갤럭시 S
솔직히 구글 순정에서 삼성전자 전용으로 코딩한다치면 그만큼 추가적인것도 많이있고 최적화 하는대도.. 시간이 더 소요됩니다...

구글 순정룸보다 용량높은 이유도있는거죠.

다른말로. 외국게임관련 내용으로 설명하면 한국어로 번역해 넣으면 원본보다 용량이 높아지죠.. 그만큼 어떻게 하느냐의따라 다양해진다고 봅니다.
Anonymous
해당 사항 없음
갤럭시 S
커널에서 쓰는 함수용어도 왜 그랬는지는 모르겠는데 다 다르더라구요.
o시론o
Active Level 8
갤럭시 S
커널 함수용어도 틀린 이유가 국내 통신사와.. 삼성전자 보안관련때문인것으로 알고있습니다. 국내,외국 지원하는 앱 환경에따라 적용되는게 틀린 이유죠.
Anonymous
해당 사항 없음
갤럭시 S
아아... 그런 사정이...
참 골치아프네요...
o시론o
Active Level 8
갤럭시 S
댓글 지우지 안했는대.. 자동으로 삭제가되었네요;;
o시론o
Active Level 8
갤럭시 S
간단하게 말씀드리자면 한번꼬이면 전체적으로 바꿔줘야함. 자동으로 삭제된 내용은 이해하셨을거로 봅니다.ㅎ
갤럭시S105G
Expert Level 4
갤럭시 S
호환성입니다
ONES20plus
Active Level 10
갤럭시 S
크으 좋은 글 감사합니다
이 글 보고 사람들이 이해해줬으면 좋겠네요ㅎㅎ
Anonymous
해당 사항 없음
갤럭시 S
저도 커뮤니티가 이 글보면서 따뜻해졌으면 좋겠습니다. 진심으로요.
아주작은쥐
Expert Level 5
갤럭시 S
동감 입니다
배고픈해골
Active Level 10
갤럭시 S
누가 요약 좀,,, ㅎㅎ
Anonymous
해당 사항 없음
갤럭시 S
음 핸드폰으로 치다 보니 힘들지만 대강요약해보자면
개발자들은 코드 외우고 복붙하는 원숭이가 아니다.
새로운 버튼을 만드는 건 버튼 사이의 인과관계를 찾고 버튼을 만드는데 필요한 요소를 찾는 것과는 전혀 다른 난이도의 스킬이 요구된다.
그래도 이걸로 합리화가 되진 않고, 당연히 다른 직업도 다 전문적이다. 나도 이렇게 생각한다.

사람들은 개발자들이 게으름벵이에 자신의 직업전문성 뒤에서 숨어산다고 생각한다... 절대 아니다.

개발자들은 계획에 많은 시간을 쏟는다. 거의 계획짜는시간=작업하는 시간이다.

뭐가 문제냐고?
문제는 너다. 넌 너의 공동체 안에서 플래닝과 피드백을 일의 중심 가치라고 여기지 않지. (의역으로 해석 추가:그래서 그들의 행동을 이해할 수 없는거다)
--저는 번역만 할 뿐입니다.--

소프트웨어 프로젝트는 이렇게 시작한다. 사업이 개발자에게 말도 안되는 휘황찬란한 xx를 준다. 현재 있는 인원의 10배는 되어야 실현할 수 있는 것들. 그리고 마감일은 그들의 상황을 고려하지 않는다. 그래서 개발자들은 당신들을 만족시킬만한 견적서를 제출하고(실현이 불가능하고 정말 고되게 일해야 될까말까하지만, 소비자를 만족시킬 것... 사실 이 부분은 저도 해석이 탐탁지가 않습니다. 다만 맞는 것 같긴 합니다.)
--사업 이란 건 아마 윗분들 을 이야기하는 것 같아요--
3달 간 양쪽 (윗분들과 개발자?)간 대화가 이루어지지 않는다.
그리고 개발자들은 다가오는 마감일에 우울해진다. 당신들과의 약속을 지키지 못할 것 같아서.
그리고 이미 타사들은 자신들이 3달간 연구한 거 비슷한 걸 내놨단 걸 알게되고 더욱 힘들어한다.

그리고 안정화를 위해 한 달이 더 필요하다.
그것은 사업과 무관하게 되고 당신을 그것을 포기하기로 한다. 그리고 그들은 당신이 그들의 직업을 존중하지 않는다고 생각하고 더욱 좌절한다.
그 뒤로는 번역문도 읽을만 합니다.
0 좋아요
배고픈해골
Active Level 10
갤럭시 S
요즘은 코딩노예가 말도 하네요(넝담)
0 좋아요
Anonymous
해당 사항 없음
갤럭시 S
어익후 엄청 길어요ㅋㅋ 저는 개발자는 아니지만 제 생각에 삼성은 소프트웨어 업데이트 그래도 괜찮게 해주는 것 같아요. 사과폰도 써보고 L사폰도 써봤었는데, A사보다 살짝 밀리는 거는 맞지만 예전보다 많이 좋아진 거 같아요. L사쪽은 쫌 느리다고 생각하고... 아무튼 저는 지금 갤럭시를 쓰고있는데 삼성 소프트웨어 업데이트 만족합니다.
Anonymous
해당 사항 없음
갤럭시 S
살짝 느리지만 그렇다고 퀄리티가 낮진 않으니... 저도 만족합니다.
다만 요번 S20은 초큼..흠
0 좋아요
JINU_
Expert Level 5
갤럭시 S
저번 댓글 이후로 잘 봤습니다. 충분히 개발자들의 말을 대변해줄 수 있는 글이라고 생각되네요
Anonymous
해당 사항 없음
갤럭시 S
좋게 봐주셔서 감사합니다.
0 좋아요
JINU_
Expert Level 5
갤럭시 S
작성자님 의견에 전적 동의하는 건 아니지만, 어떤 일이 있든간 그걸 중립적으로 보고 양쪽의 입장을 모두 이해하는 게 참 중요한 것 같습니다. 좋은 일요일 되셨길 바랍니다 👍
0 좋아요
호라드림
Expert Level 3
갤럭시 S
ㅎㅎ 저 번역문장이 세상모든 개발자의 대변문구인가요
결국 책임을 어디에 물어야하나요?
명쾌하게 답을 내주세요

개발자는 저런 애로사항이있으니 신성불가침의 존재니 누굴원망하면 되나요?
번역기 내용대로라면 소비자를 탓하라는거 같은데 맞게 해석했나요?
0 좋아요
Anonymous
해당 사항 없음
갤럭시 S
아니요 잘못해석하셨습니다.
0 좋아요
양현수
Active Level 3
갤럭시 S
네 맞습니다.
0 좋아요
양현수
Active Level 3
갤럭시 S
이녀석 이
0 좋아요
양현수
Active Level 3
갤럭시 S
좋아하고 사랑하는 너를 위한 선물
0 좋아요
양현수
Active Level 3
갤럭시 S
사실 난 궈물이야 뻥이지메롱
0 좋아요
양현수
Active Level 3
갤럭시 S
0 좋아요
양현수
Active Level 3
갤럭시 S
그러네요
0 좋아요
양현수
Active Level 3
갤럭시 S
워안헤
0 좋아요
양현수
Active Level 3
갤럭시 S
워안하냐고😡
0 좋아요
양현수
Active Level 3
갤럭시 S
빨리해
0 좋아요
양현수
Active Level 3
갤럭시 S
빨리 하라고
0 좋아요
양현수
Active Level 3
갤럭시 S
워안해
0 좋아요
양현수
Active Level 3
갤럭시 S
오잉?
0 좋아요
양현수
Active Level 3
갤럭시 S
누가 친구 를 삭제 했어?
0 좋아요
양현수
Active Level 3
갤럭시 S
빨리 working 해.
0 좋아요
양현수
Active Level 3
갤럭시 S
미안해
0 좋아요
양현수
Active Level 3
갤럭시 S
뭐 가 미안해?으아아아아아아아아아아아아아아아아아아₩₩₩

20210204_182739_501.jpg

0 좋아요
양현수
Active Level 3
갤럭시 S
이녀석 이
0 좋아요
양현수
Active Level 3
갤럭시 S
😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡👺👺👺👺👺👺👺👺👺👺👺👺👺👹👹👹👹👹👹👹👹👹👹👹👹🤢🤢🤢🤢🤢🤢🤢🤢🤢🤢🤢🤢😱😱😱😱😱😱😱😱😱😱😱🤪🤪🤪🤪🤪🤪🤪🤪🤪🤪🤪🤪🤪🤪🤪💀💀💀💀💀💀💀💀💀💀💀💀💀💀😇😇😇😇😇😇😇😇😇😇😇
0 좋아요