Como programador, o que devo saber como as costas da minha mão? [fechadas]


8

Estou falando de coisas relacionadas apenas à programação e não à administração de sistemas ou redes.

Estou prestes a terminar a faculdade e conseguir um emprego em programação, por isso estou interessado em saber sobre isso. Embora isso possa parecer uma pergunta subjetiva, acho que isso não é verdade e se enquadra na categoria de melhores práticas.

Eu não acho que um programador possa saber tudo sobre o SO em que trabalha, todas as APIs da estrutura em que trabalha, todos os recursos e peculiaridades das linguagens com as quais trabalha, todas as estruturas de dados e algoritmos, todas as configurações para sua compilador, vinculador, IDE etc. Eu também não acho prático. Ou ele pode?

A resposta usual é "mais". O que é isso mais? Se você entrevistasse um programador com cerca de 5 anos de experiência, o que esperaria que ele soubesse? Ou, digamos, se você comparecesse a uma entrevista e tivesse cerca de 10 anos de experiência, com o que retocaria?


2
É totalmente depende do tipo de trabalho. O que você precisa saber para a web de front-end é diferente da web de back-end. Que é diferente do incorporado, que é diferente do trabalho OS ...
Oded

1
Olá Michael, bem-vindo aos programadores! Embora isso possa ser um ótimo tópico de discussão, é um tópico muito amplo para o estilo de perguntas e respostas do Stack Exchange . Se houver algo específico sobre desenvolvimento de software que você queira que alguém lhe explique, fique à vontade para perguntar sobre isso.

2
Você deve conhecer seu teclado como a palma da sua mão.

2
Não entendo por que esse tipo de pergunta é fechado continuamente. WTF. O cara acabou de sair da faculdade. Ele é um Jr. Portanto, suas perguntas serão abertas e inespecíficas. Ele provavelmente nem sabe o que perguntar, e é por isso que as respostas que ele provavelmente quer são algo que possa ajudá-lo. Ele quer uma visão geral. Você não precisa de um escopo específico para responder à pergunta dele. As respostas neste tópico são excelentes. Mesmo que isso tenha sido perguntado 100 vezes, quem se importa, você receberá respostas novas e diferentes e totalmente novas que são ainda diferentes das de outros tópicos.
WeDoTDD.com

1
Este é um problema com a pilha. O ponto principal do fórum dos programadores é que você pode fazer perguntas específicas e / ou subjetivas que pesquisam, dão opinião, argumentos etc. A opinião é o que gera boas respostas para uma pergunta como a dele. Todo mundo já teve sua própria experiência na indústria de software, então a opinião é exatamente o que esse cara precisa. Ele precisa de uma variedade de idéias, experiências e insights aqui. Então, o que se eles não estão específico, trata-se de conselhos gerais carreira ..
WeDoTDD.com

Respostas:


14

Você precisa saber:

  1. Como pensar. Se você não consegue pensar, vá trabalhar em outra profissão.
  2. Saiba onde procurar. Você não precisa saber tudo sobre algo, precisa saber o suficiente para ser útil e o suficiente para PENSAR "ei, precisa haver uma maneira de fazer o X" e depois procurar.
  3. Conheça seus limites. Isso significa suas habilidades, sua falta de conhecimento, o fato de você não saber tudo (e nunca saberá). Um pouco de humildade ajuda bastante.

7
humildade é rara em nossa profissão, eu concordo. Precisamos de desenvolvedores mais humildes que possam dizer de vez em quando, ei, eu não sei como x, y ou z e não temos medo de baixar a guarda e fazer perguntas ... até mesmo arquitetos fogem ... precisamos de desenvolvedores que realmente se preocupam em trabalhar juntos, não de desenvolvedores egoístas que pensam que são deuses e se isolam em seu próprio mundo divino no trabalho.
WeDoTDD.com

@CoffeeAddicat: +1. E te daria mais se pudesse.
precisa saber é o seguinte

1
@CoffeeAddict: Ser humilde é mais classificado na minha humilde opinião. Café, por outro lado, não é ... :-)
erros

3
@ Coffee - Existe uma completa falta de humildade em nossa profissão pelo que vi. Quando eu trabalhava em um banco de investimento, costumava ir até meu chefe e fazer perguntas sobre coisas que não entendia e ela levantava a voz tão alto que todo mundo ouvia. Essa foi obviamente uma tentativa patética de me fazer sentir mal por fazer perguntas.
Desolate Planet

1
@Desolate sim, eu ouço sua dor. Não devemos ter que aturar pessoas assim em uma profissão de engenharia. É um problema de atitude da maioria dos desenvolvedores por aí (não estou dizendo tudo). Não entendo por que deve haver uma guerra de "sou mais esperto que você" e uma enorme falta de respeito por seus colegas ... a esse respeito. Todos devemos trabalhar juntos ... aprender e seguir em frente.
WeDoTDD.com

8

A Matriz de Competências para Programadores é uma lista de verificação suficientemente boa e é uma leitura fácil e informativa a partir de uma única fonte.

O blog clássico de Norvig sobre " Aprendendo a programar em 21 dias " também é uma boa leitura.


@ Expressões: Sim, não há problema - a princípio, embora a pergunta fosse como se poderia adivinhar um pouco, terminou, mas pensei nisso e desenterrei essa lista de verificação que encontrei alguns anos atrás.
erro

Sim, eu também gosto deste ... bom.
WeDoTDD.com

3

Gostaria de comentar sobre isso, porque acho que, embora essa pergunta provavelmente tenha sido feita muito nesses fóruns, não importa, você tem perspectivas diferentes toda vez que é solicitada.

Com isso, aqui está minha experiência e acho que "sabedoria ou coragem" em nossa profissão. Parte disso se sobrepõe ao que outros já declararam, mas estou listando minha experiência e, em seguida, minha filosofia / opinião / sugestões para cada um de nós.

1) Sim, como outros já declararam, você precisa ter algum nível em que seja capaz de digerir idéias complexas, processar e poder trabalhar e encontrar suas próprias soluções em código para problemas. Por outro lado: você pode aprender a se tornar um melhor solucionador de problemas ao longo do tempo, se tiver muita motivação positiva para continuar insistindo, trabalhar duro e fazer muitas perguntas. A maioria dos desenvolvedores que dizem que sabem tudo ou tentam parecer simplesmente escondem o fato de terem feito muitas perguntas, trabalhado em código etc. para chegar onde estão e ficar tão bons quanto possível. eles parecem ser

2) Na nossa indústria, novamente na minha opinião, infelizmente existem muitos egos. Eu não vejo isso como uma coisa boa e é especialmente uma característica para muitos desenvolvedores por aí.

O que você encontrará na minha experiência é um dos seguintes tipos de equipes:

  • Equipes de "Code & Run". Isso significa que tudo o que eles querem é sair rapidamente da porta, eles podem se importar menos com a qualidade do código (código limpo) ou com o código que pode ser mantido posteriormente. Fique longe dessas lojas, se puder. É difícil porque, mesmo que você analise uma empresa em uma entrevista, não saberá realmente como a equipe opera até que você consiga o emprego e tenha entre quatro e seis meses para ver realmente como eles codificam ou se realmente promovem o trabalho em equipe e fomentar a colaboração (idéias, etc.)

  • Loja média de desenvolvedores que está "ok". Isso significa que eles se preocupam um pouco com a qualidade do código. Eles podem ter alguns bons desenvolvedores na equipe que trabalham bem em uma equipe e têm uma atitude positiva e, em seguida, uma mistura de alguns desenvolvedores que podem ter outros traços, como egoísta, preguiçoso, etc. mas onde o código não é o melhor, mas é tolerável

  • Ótima loja. Esta loja faz o possível para seguir realmente bons padrões de design. Eles podem não ser especialistas em padrões de design, mas conhecem boas práticas, como DRY, SOLID, qualquer outra coisa. Eles não esperam necessariamente que as superestrelas se juntem à sua equipe, mas estão procurando desenvolvedores que estejam pelo menos codificando um pouco de código limpo e tenham uma boa experiência primeiro. Estas são as equipes pelas quais você deseja avançar ... mas você pode precisar percorrer algumas lojas para encontrar boas equipes

  • Loja de Superstar. Esta é uma loja que procura apenas os melhores programadores absolutos, mas também os programadores com melhor significado que têm tudo. Eles se comunicam bem e trabalham bem em equipe (positivamente com os outros para o melhor do tema). Lembre-se de que todas as lojas lhe dirão sim, só procuramos o melhor. A maior parte disso é bobagem ... eles têm boas intenções, mas muitas vezes é apenas conversa de marketing. Mas há uma porcentagem de lojas que realmente procuram os melhores talentos. E você saberá que quando entrar na entrevista e eles estiverem fazendo perguntas sobre encadeamento, padrões avançados de design etc. Então ... para chegar a esse nível e se você quiser trabalhar em uma equipe que tenha esse tipo de expectativa , pode levar alguns anos para chegar lá

  • Loja Superstar com vibrações / egos negativos. Existem lojas por aí que contratam os melhores desenvolvedores, mas onde a maioria dessa loja pode ter um monte de idiotas que são superestrelas. Portanto, existem equipes que simplesmente não toleram códigos incorretos, mas são verdadeiros truques sobre isso. Não é um ambiente de equipe e você quer ficar longe dessa porcaria. Nossa indústria não precisa disso e você também não

e um dos seguintes tipos de desenvolvedores por aí:

a) Ego enorme, sabe tudo, sempre quer manter distância de tudo, revela pouco, tem atitude ... essencialmente não é um jogador da equipe e nem alguém com quem você deseja trabalhar ou ter na sua equipe

b) Devs que estão lá apenas para fazer um trabalho medíocre, fazer o trabalho e ir para casa. Pessoalmente, acho que não há nada de errado com isso do ponto de vista inicial, mas ao mesmo tempo acho que nossa profissão precisa de desenvolvedores apaixonados e dispostos a sacrificar e desfrutar de seu ofício para, finalmente, agregar valor, mas também para melhorar como desenvolvedor a longo prazo. transportar porque se preocupam em se tornar melhor

c) Devs que provavelmente poderiam fazê-lo, mas são muito preguiçosos, negativos ou quaisquer outras características que possuam, que causam o inferno para todos, mas principalmente por causa do fator preguiça. Não gostaria que pessoas preguiçosas na minha equipe ... engenheiros preguiçosos não são o que precisamos em nossa profissão

d) Desenvolvedores que são bons para grandes desenvolvedores, que se preocupam com o trabalho em equipe, que desejam se humilhar, ensinar aos outros, se comunicar e estar aberto a críticas construtivas sobre processo ou código (revisões de código etc.) e simplesmente se preocupam em ser positivos no trabalho enquanto trabalham como desenvolvedores com todos os colegas. Você quer trabalhar com esse tipo de pessoa, um ambiente de desenvolvimento de suporte positivo. Agora, não estou dizendo que uma equipe deva procurar leachers ... você precisa ser capaz de aguentar seu próprio peso, mas não quer terminar em equipes nas quais eles esperam que você seja um desenvolvedor "estrela" e para nunca fazer perguntas ... esse é um ambiente ruim. Fique longe disso ... é difícil encontrar esse ambiente, na minha opinião, em nossa profissão como um todo, na experiência de meus e de outros amigos ao longo de nossas carreiras. Você pode encontrar boas equipes, mas elas são mais difíceis de encontrar do que aterrissar em lojas caóticas com más atitudes. Portanto, saiba no que você está se metendo, a grama nem sempre é mais verde, apenas porque os desenvolvedores são chamados de "profissionais". Tenho certeza de que isso pode estar relacionado a qualquer trabalho, provavelmente, mas penso mais com nossa profissão do que com a maioria dos outros por aí.

3) Uma coisa que aprendi da maneira mais difícil é que, se você é um perfeccionista e se preocupa muito com o bom processo e o código perfeito, isso vai causar problemas algum dia. Encontre esse equilíbrio. Você não quer um código desleixado e não perde muito tempo a ponto de seu empregador ficar chateado porque levou duas semanas para realizar uma tarefa de tamanho relativamente médio, que geralmente deve ser feita, digamos 3-4 dias porque você queria que fosse muito limpo. Um bom livro para ler e bom rapaz para seguir em nossa indústria é "Tio Bob". Eu sou um grande fã dele, assim como muitos desenvolvedores por aí. Leia as postagens dele no código e compre o livro dele. Não posso dizer quanta sabedoria e experiência ele tem para oferecer às pessoas, inclusive a você, que acaba de sair da faculdade sobre nossa profissão em termos de melhores práticas, atitudes,

o blog da empresa: http://blog.objectmentor.com/articles/category/clean-code (e confira http://blog.objectmentor.com/articles/2009/02/03/speed-kills )

um de seus muitos bons livros que acho que todo desenvolvedor deve ler ou ter lido e publicado na sua estante: http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Seu blog pessoal: http://cleancoder.posterous.com/retarded-architecture

E um bom vídeo dele em uma conferência que ele falou: http://www.viddler.com/explore/oredev/videos/36/

4) Não se estresse em competir com todos os desenvolvedores com os quais trabalha. Você precisa perceber que você levará alguns anos para dominar o básico de nossa profissão, mesmo que você tenha se saído bem no CS. Leva tempo, trabalha duro, faz perguntas, pesquisa, seja paciente ... e, especialmente, como nossa indústria está agora em tal fluxo, não fique frustrado se não souber tudo. Concentre-se no básico primeiro ... conheça-o bem nos primeiros anos. Não complique demais as suas preocupações, você é um desenvolvedor Jr. tentando melhorar e isso acontecerá se você trabalhar duro e melhorar primeiro o PO básico. Muitos desenvolvedores de nosso setor ainda não conhecem os fundamentos porque não se esforçaram para conhecê-los, o que é negativo. Você quer conhecer bem os fundamentos primeiro (polimorfismo, Encapsulamento, yada yada). Se você não tiver muitas oportunidades de fazer muita POO em seus primeiros trabalhos, faça um grande esforço para pesquisar e praticar em casa, brincando com código com algum projeto divertido para animais de estimação do lado que você gosta.

Eu poderia fazer esse post mais, mas vou parar por aqui. Se você tiver mais perguntas por meu post, basta responder nos comentários e podemos continuar discutindo.

Em última análise, se você é um gênio, super esperto, esperto, medíocre ou péssimo, não importa quem você seja, em que nível, se você quiser fazer parte de nossa profissão, sempre terá que trabalhar muito e tentar aprender continuamente e melhore a si mesmo e almeje o melhor que você pode ser (código, comunicação etc.). Nossa profissão não é de menosprezo.


Gostaria de acrescentar que resolver e particionar problemas flagrantemente complexos é apenas o segundo passo. O primeiro é realmente reconhecer que existe um problema e qual é o problema.
John Weisz

1

Como descobrir o que você não sabe o mais rápido possível ...


Você quer dizer encontrar o que não sabe ou encontrar a resposta para o que não sabe? Saber o que você sabe, o que você não sabe e o que você não sabe, só o levará tão longe. Aprendizagem de fazer, não sabendo se o caminho para o caminho brilhante do futuro ... :-)
erros

Fazer coisas erradas leva ao sofrimento, fazer coisas que outra pessoa pode fazer mais rápido e melhor leva ao sofrimento, saber quem e onde procurar ajuda é o caminho para o caminho brilhante do futuro! O caminho para muitas pessoas de nível júnior sentar e guiar coisas que seriam muito mais fáceis de pedir ajuda e realmente aprender a pescar antes de sair e construir um barco quando não precisar!

Eu não sei, embora eu concorde que assistir alguém bater a cabeça sem pensar em uma parede seja algo doloroso de se observar, também acredito que muitas vezes as pessoas roubam a outras pessoas a chance de simplesmente falhar, aprender com ela e seguir em frente . Falhar na minha opinião é uma grande parte do aprendizado.
erros

0

Tendo aproximadamente 10 anos de experiência, eu aprimorava os algoritmos (classificação, estruturas de dados, gráficos). O maior problema para mim é que meus últimos anos foram dedicados a uma função de liderança ou lidando com problemas de arquitetura de nível superior que geralmente não exigem design e análise de algoritmo de nível inferior como quase tudo o que você precisaria naquele momento. O nível já foi escrito, otimizado para o inferno e foi testado em batalha.

Também passaria algum tempo no projecteuler.com e no entrevistastreet.com resolvendo problemas para me ajudar a aplicar esses aprendizados recém-aprendidos para ajudá-los a permanecer.


0
  1. Aprenda matemática. Programar é matemática se você remover os efeitos visuais.
  2. Use o idioma certo para o seu programa. Então, conheça pelo menos os recursos dos idiomas.
  3. Passe algum tempo no algoritmo antes de codificar. Se você estiver codificando como membro de um grupo, estude o algoritmo juntos.
  4. Se a velocidade de execução é um problema e se você é livre para corrigir o código de uma arquitetura, use as rotinas especializadas para sua CPU, GPU etc.
  5. Passe um bom tempo para depuração e teste.
  6. Seja curioso sobre quase tudo sobre programação. Você aprenderá com o tempo.

0

Conheça o seu algoritmo e estruturas de dados completamente. Saiba como realizar tarefas comuns com o idioma / estrutura e como um especialista faria o mesmo. Trabalhe, cometa erros, melhore e deixe sua experiência lhe ensinar mais enquanto você estiver no setor.

Minha lista de verificação para uma entrevista seria

  1. Classificação, Pesquisa, algoritmos gráficos e básico de Programação Dinâmica.
  2. Matrizes, matrizes, pilhas, filas, listas vinculadas, árvores e tabelas de hash.
  3. Conceitos de Programação e Teste Orientados a Objetos

Não se esqueça de ter em mente a complexidade de tempo e espaço de suas soluções, se você deseja uma dessas grandes empresas que as pessoas sonham em entrar :).


Best of Luck


1
"Conheça bem o seu algoritmo e estruturas de dados": essa é uma afirmação bastante assustadora, dado o grande volume de cada uma ... Talvez seja um pouco mais específico para uma entrevista de nível básico.
Demian Brecht

Obrigado Damien pela sugestão. Editado para ser mais específico.
Priyadarshi Kunal

3
@demian e, de fato, é falso. Por exemplo, quando eu quiser classificar uma lista, frequentemente chamarei .sort () no objeto de lista.

@Lee A solução de problemas para aplicação na vida real pode / será / pode ser diferente de resolvê-los na entrevista. Um entrevistador provavelmente gostaria que você resolvesse um problema em vez de simplesmente respondê-lo.
Priyadarshi Kunal
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.