23 ms·
Ask HN: What is the first thing you implement at a new company?
For job-hoppers and contractors. If you arrive at a company, what is the first thing you push for?
For instance, I usually implement a good feature-branch flow with branch pipelines and a strict merge-to-develop etiquette with mandatory merge requests. It makes my work easier and once the team is used to it, they also really like it. No more messy development branches.
I also request a small office stool next to my desk to make code reviews, three amigos and pair programming easier. It is a small thing but I noticed that people are more eager to discuss things if they have a place to sit.
- phoenix24 8y agoCI/CD. Revision Control. Artifactory. VPN.
- dboreham 8y agoVPN?? For what?
- ThePadawan 8y agoNot parent, but generally to be able to do remote work. Production goes down and you're not at the office (1h travel)? Now even a 1min fix will cause 1h + 1min of downtime.
- heavenlyblue 8y agoSo is your cloud in the office then?
- EamonnMR 8y agoThe cloud can also be on a VPN.
- vortico 8y agoWhat's three amigos? Never heard that term in programming.
- clemParis 8y agoI had to google that as well. It seems to be an agile practice [0] that consist in gathering a developer, a product owner and a QA tester in order to produce acceptance tests using the format given/when/then. [0] http://jonkruger.com/blog/2012/01/04/the-three-amigos/ http://jonkruger.com/blog/2012/01/04/the-three-amigos/
- BerislavLopac 8y agoNice. I suppose the code is the singing bush then. And the end user is the invisible swordsman [1]. [1] https://www.youtube.com/watch?v=e9vPvHO8Kp4 https://www.youtube.com/watch?v=e9vPvHO8Kp4
- mhd 8y agoWho came up with that, given that "three amigos" is a pretty well-known term for Booch, Rumbaugh and Jacobson?
- triggercut 8y ago1.Find an established religiously held standard that has little actual value (tabs vs. spaces). 2.Spend the first month gas-lighting everyone into changing to the oposite until enough people force a change in policy. 3.Survey my new kingdom with my loyal band of disciples (whilst intermittently switching between tabs and spaces to enrage the holdouts) 4.Quit
- fastbeef 8y agoFor the first month or so I take a very humble listening position, even if I immediately see things I want to fix. More often then not, there is a background and a history to things that could lead to a) my “fix” being unnecessary and/or ill-informed and b) friction with the rest of the team because here comes a whippersnapper upending all our stuff. Process and code fixes are _much_ easier once you have good rapport with the team.
- makmanalp 8y agoThis honestly took me a while to learn - it's so easy to jump in and be a smartass (and I've been guilty of this before) about how bad things are, but a) suggesting small, incremental changes that demonstrate a nuanced understanding of where things went wrong and b) volunteering to work on making things better goes a long way. Most of the team will already often know and agree on what is bad - but just won't be empowered to fix it somehow.
- minor3rd 8y ago> This honestly took me a while to learn Yeah same here. I think I pissed off my manager pretty quickly at my current job by trying to change how they did certain things before getting an understanding of why they did them that way, but I realized my mistake and went into more of an observer-mindset for awhile. Over time I built up a reputation with reducing friction in smaller ways on specific features I worked on, and then applied that same thinking to larger scale issues I saw. They were much more receptive once they knew I could make valuable contributions, and now I'm one of the main people establishing patterns and architecture decisions at my company. Learning to establish myself for awhile before making process changes was a great learning experience that I plan to take with me to all future roles.
- krenel 8y agoYour comment resonates with me. I work hard to improve things; most of it was worth it, some of it didn't went well but it was a constant fight with my boss. If I failed, he would bring it back for months. What worked for me was to step back and get into super pasive mode. Give all the responsability to my manager. I didn't question any of his design decisions, gave support to all ideas even if seem plain wrong unless he wanted honest feedback (usually, he didn't because I would change the original idea). Never say or even insinuate "I told you this was not gonna work"; I just acted surprised and asking to him "ok, what do we do now?". It just took a few months for my manager to start reliying on me, more and more. Now I have even more space for improving things, with the full support of my manager because "he wants me to do it" not "because I push my ideas to him". At the end of the day, it's not dumb if it works.
- apfel912 8y agoCI/CD Dockerize all the things
- leksak 8y agoWhere do you stop short? I'm conflicted. I sometimes look at Docker and am like "this is great", but I also sometimes look at a plethora of Dockerfiles and I'm like... what are we doing wrong? Do you, for instance, Dockerize small Python tools (or similar)? How well does this work? I remember one project where we had tons of small Pipenv projects and one pain was that a few were Python 3.5 and a few others were Python 3.6. I guess Dockerizing these would have mitigated the pain but honestly I am a complete Docker n00b and wouldn't know how to go about setting this up in a way that wouldn't cause more pain and another layer of abstraction. Any tips? Reference material, etc?
- yorwba 8y ago> we had tons of small Pipenv projects and one pain was that a few were Python 3.5 and a few others were Python 3.6 Isn't pipenv supposed to take care of that? You pipenv run the tool and it's automatically executed in the right virtual environment.
- leksak 8y agoYou can't set it up without the Python binary you want already being on the machine which may be a hassle if you are chasing "latest" and you have machines in your ecosystem that run old stuff, for instance, Jenkins nodes.
- thijsvandien 8y agoYou'd have to combine it with pyenv to allow for multiple interpreters and automatic switching between them.
- troels 8y agoThe first thing I do is work to gain enough political leverage so that I can manage my own time.
- mosselman 8y agoCan you give an example of how you’d do this?
- raverbashing 8y agoUnnamed envelopes left on people's desks?
- troels 8y agoIn the broadest sense, by gaining the trust of people and by showing initiative, rather than waiting for someone else to dictate what I should be working on.
- yitchelle 8y agoSounds like a nasty place to be in if the first time you do is politically based.
- falcolas 8y agoIt's a hard lesson, but everything in a company is driven by politics. Technical skills will only get you so far - maybe to the senior individual contributor position. Beyond that, your job will include communication, evangalization, and compromise.
- troels 8y agoI realise the way I put it may sound ominous, but it's for the good of everyone involved really. Most organisations are shockingly ineffective. Micromanagement and lack of long term planning is abundant. I get hired because I'm good at writing software. This is not wrong, but I can add much more value if I deliver what is needed rather than what is asked. My goal is simply to be able to do that.
- JeanMo 8y agostatic code analysis e.g. Sonarqube. CI/CD
- blattimwind 8y agoCI. Code analysis. Revision control. Something for documentation.
- thecolorblue 8y agoThis is not technical, but I always push for monthly performance reviews, with clear goals, and a weekly dedicated time to check in with a manager once a month to make sure I am spending my time on the right things. It doesn't always happen, but my experience has been the harder it is to get these things the less likely I will feel productive.
- gpetukhov 8y agoLinting and code style guidelines. Easy to introduce, but makes a big positive difference.
- colinbartlett 8y agoIn that vein, I invariably have one massive commit on every project to remove trailing whitespace first. That way when my well-behaved editor removes them with each commit, it's not littering up the diff.
- dmichulke 8y agoFrankly, I saw this in a few projects and it feels like the responsible is one of those people that can't actually code but wants to convince management of their impact with their huge commit stats. I also hate whitespace but it's just a symptom (the other developers' editors / git config probably don't show the trailing whitespace). Given this, it's a mere symptomatic remedy, the problem will reappear, and the only person benefiting from this is you. I'd hate to pay you for that.
- klibertp 8y agoFor what? 30 seconds of writing a sed command in the shell? I can donate that kind of time to the project for free, really.
- steve_adams_86 8y agoI think the process would include having the team become aware of the situation and improving their editor configuration to stop littering whitespace everywhere. Otherwise I agree, that seems like a waste of time to do in isolation. I'd probably address it more completely if so many files are going to be touched, and whitespace is only one symptom of bad formatting connections. Perhaps everyone should employ the same formatter on save, for example. There is far more value in that. Getting rid of only superfluous whitespace is a bit of a time sink for what you get in return (as much as it drives me nuts).
- 8y ago
- Jayvino 8y agoI connect to the mainframe and then execute variables on the system. This gives me access to data I would otherwise not have.
- BerislavLopac 8y agoUpdate the codebase to Python 3.6.
- dswalter 8y agoF-strings alone make the upgrade worth it.
- colinbartlett 8y agoCodeClimate is a big one for me. Having some static analysis to track the team's progress over time is huge. It's nice to have a neutral third party robot doing the complaining about poor code. Fortunately, CI/CD seems to be pretty prevalent these days. But if it's not in place, that's always first.
- stealthmodeclan 8y ago1. Every now and then we run into Paywall. Give everyone employee debit card so that they can buy stuff which helps their productivity. 2. CI using Drone.io 3. Add trello 4. Everyone gets their own AWS account. It makes it trivial for them to experiment with new ideas from their home or at office without begging anyone for credentials. You start by empowering your employees. Now, we consult startups which work differently so you might not have capacity to make these changes.
- izolate 8y agoDo you have a list of companies you consult for by any chance?
- readhn 8y agohaha. seriously?
- bpicolo 8y agoMy company is currently using drone. The lack of first class scheduled builds is a real buzzkill. Jenkins or similar feels like a much better solution atm still (you can still push for containerizing jobs either way)
- raziel2p 8y agoJenkins's main problem for me will always be the lack of focus on storing pipelines/jobs as source code. Jenkinsfiles are horrible both to read and write.
- robax 8y agoI'm new to devops and thought it was crazy that Jenkins only recently implemented codified jobs (jenkinsfiles) and they truly are horrible to write. Does anyone have any suggestions to resources or alternatives to jenkinsfiles?
- metakermit 8y agoLately I've been adding prettier.io to all the new projects I join. Great helping tool :)
- jdwyah 8y agoFeatureFlags for sure. They don’t force anyone to change their day to day but allow them to adopt better practices at their own speed.
- onion2k 8y agoCompany funded Friday lunch.
- readhn 8y agowith opportunity for employees to pick their own lunches.
- astonex 8y agoIf you just arrived at a company why are you pushing to change anything. They obviously already have a working process and you should be careful to change anything that works, especially when you may not yet know all of the more hidden details.
- bytasv 8y agoEven if the process that they have is working it doesn't mean that it can not be improved. And if you obviously see the parts that could be improved because you already stepped on the same rake many times why not do that? Ofc as a newcomer trying to change things you are always gonna be welcomed with strange looks but that's another side of it - how to implement the changes so that everyone is happy...
- arethuza 8y agoMore at a management level, but I have joined small commercially successful companies who had utterly dysfunctional development processes (backups? revision control? sane deployment processes?....).
- hurryharry 8y agoI second this - there is so much to absorb when joining a new team/company. Absorb as much as you can about process in place. Ask plenty of questions. So I would suggest to setup few meetings with right people just to get thigns in place.
- lvh 8y agoThere are lots of useful changes you can make that don't break the world but do materially improve things. I already gave an example elsewhere of aws-vault. Similarly, CI/CD/code review are easy wins that not everyone has already. You're assuming everything is copacetic right now, but that's not a given. I doubt any startup would take the position that there's nothing left to improve. That doesn't mean you're going to start by burning the world down and starting over.
- PeterisP 8y agoIt depends on why you're brought in to the company. Especially in management it's not uncommon to hire people with the explicit notion that they don't have a satisfactory working process, it needs significant changes to achieve the desired results, and the new hire would be expected to start fixing the current process almost immediately.
- LoSboccacc 8y agoIt war rare to find places with automated build. My first priority was always to get humans out of the equation because as a contractor you need to trust the pipeline and you need to be sure whether your code hit production or not since it’s critical in issue management.
- pards 8y ago>> For the first month or so I take a very humble listening position .. and then - Everything in source control - CI - Static code analysis - Artifact repository - Automated deployments, incl database and configs - Branching strategy & pull requests - Standalone dev env per developer
- chatmasta 8y agoWhat do you use for an artifact repository? I’m assuming you mean the cached artifacts of builds, but also vendor artifacts/cache like npm_modules or docker containers? This sort of vendor dependency management is a problem I haven’t found a great solution for yet. I’m actually thinking about creating a product that’s implemented as a proxy and supports multiple package managers, including docker, and caches all downloads keyed by branch. This way in the event of some catastrophic dependency failure you have a place to find the last working set of vendor dependencies that didn’t break the build. Would anyone be interested in this? What is current best practice for this workflow?
- jzl 8y agoOne popular option: https://jfrog.com/artifactory/ https://jfrog.com/artifactory/
- wozmirek 8y agoWiki - confluence has a nice flat cloud offer for $10/mo for up to 10 users. Not only for tech people, but also for non-techs: marketing, sales, office people. And you can connect it to jira.
- macht 8y agoI go from git to SVN. It's just easier for me to work with and once the team gets used to it, it's a win-win.
- aetherspawn 8y agoSVN is really heavyweight for branches and tags. It used to take like a minute to branch with SVN but when we swapped to git it took like less than a blink. Also —rebase is way better than merge. I haven’t had to merge git for over 6 months but with SVN I was doing it twice daily, at least.
- vijucat 8y agoIf you use a repository URL rather than a local filename / dirname in svn copy, it's a purely remote copy and is instantaneous: $ svn copy file:///var/svn/repos/test/dir1 \ file:///var/svn/repos/test/dir1_jira_1886 -m "For bugfix to SERV-1886" http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.htm... https://svnvsgit.com/ https://svnvsgit.com/
- aetherspawn 8y agoMost of our team just used Tortoise SVN and the right click -> branch explorer integration. We definitely were not pros at source control.
- vijucat 8y agoAh, I see! Tortoise SVN is great for the scenario where business users can learn and use revision control, too, but I guess once you're doing branching using Tortoise SVN, you're in a weird territory where you're pro, but not to the extent you're ready to use the command line...
- isostatic 8y agoWe used to have a large (>20GB) svn repository, I never noticed tags (which was part of the build process) taking any time, certainly sub-second. However the branching process in svn is a right pain, if you work in branches. Depends on what your code is if you need the overhead and risk of branches I guess.
- elliotpage 8y agoAbolish overbearing dress code, if one exists. Social/lunch outing on Fridays.
- ben0x539 8y agoWell, first I gotta rebuild the release process on top of nixpkgs, then, after rewriting the core product in rustlang, I can focus on replacing all the developers' macbooks with linux machines.
- maxxxxx 8y agoI already want to hire you!
- garyphilip24 8y agohello mate,you can always reach anytime for any Hacking Job,I am Gary Philip,a Cerified Ethical Hacker.just send me an email :-garyphilip24@gmail.com I am up for you 24Hrs/7 days a week.
- deleted 8y ago[deleted]
- spiritcat 8y agoFirst day I find the best dev and kick his ass. Gotta set the tone.
- dboreham 8y agoThis is such a great thread.
- thecupisblue 8y agoPee on their desk. Establish territorial dominance.
- skocznymroczny 8y agoMake sure to get a MX Blue mechanical keyboard, so that everyone is aware of who's doing most of the keyboard mashing around the office.
- kennydude 8y agoDocument things to get an idea what's going on. Add comments and probably tests (but don't rewrite) to the 2 page function to see if you understand the style of the previous developers.
- nelsonic 8y ago#tl;dr Regardless of how long you stay with a company/team always leave it better than you found it. Requirements Gathering, Paper Prototype, MVP, UX-testing, Docs, Tests, Linting, Static Analysis, Git/GitHub Workflow, Team/Personal Learning, Code Quality, CI/CD, Pipelines. #longform Assuming the company is new to me but has already been writing/shipping code for before I arrive ... I ask clarifying questions to get "up-to-speed": 1. What is the Problem? - Understand what problem they are trying to solve, do users actually realise they have the problem or is it a case of "build it and they will come"...? (it's vital to know why we are building something to avoid wasting lots of time on something people don't want! see: Bill Gross "Why Startups Succeed": https://www.ted.com/talks/bill_gross_the_single_biggest_reason_why_startups_succeed https://www.ted.com/talks/bill_gross_the_single_biggest_reas... or Paul Graham "Make something people want": http://www.paulgraham.com/good.html http://www.paulgraham.com/good.html A "red flag" is when there are no clear "personas" for prospective users. see: https://www.interaction-design.org/literature/article/personas-why-and-how-you-should-use-them https://www.interaction-design.org/literature/article/person... 2. Workflow? - Is there an existing clear "workflow" for collecting requirements, defining user stories and getting the features built and UX-tested? or is it all verbal between "founders" and the one dev? (comes back to how old/new the company is; is it a brand new "startup"...?) 3. MVP Defined? - What "MVP" has already been shipped? who built it? what tech was used? was the work "outsourced" e.g: to remote contractors or an "agency"? was a revision control system used e.g: GitHub? If no MVP has been shipped, is it at least clearly defined in the backlog? 3.a Paper Prototype?: what is the minimum you can do to test an idea? See: "Google Ventures Design Sprint": http://www.gv.com/sprint http://www.gv.com/sprint & https://youtu.be/Z8MOwcqZuuU https://youtu.be/Z8MOwcqZuuU 4. Technology & Tool Selection - If the personas & problem is well defined, and minimum features captured in a "backlog", then we can discuss technology choices. It's essential to have these choices documented somewhere, because this question will come up in the future and "because it's popular" on https://stackshare.io https://stackshare.io is not a good reason for selecting a tech/tool; whereas "it was the best choice for our specific problem/domain" is a good reason to choose a tech/tool e.g: https://github.com/dwyl/technology-stack https://github.com/dwyl/technology-stack For example: if you're building a robust real-time messaging system, use Elixir/Erlang every time. If it's just a "low budget quick-to-market" MVP to get a demo out to start testing and get "funding", use Meteor: https://www.meteor.com https://www.meteor.com (and accept the "technical debt"!) 5. Developer Workflow - Documentation Driven Development: If it's not already being done, focus on this first, without clear docs for the work done, "you're going to have a bad time" when trying to understand (never mind "fix") things in production. - Test Driven Development: If tests aren't already being written, understand why and fix it. Should you follow ("strict") "Test First Development"? Or is it "OK" to write tests after the code? The answer is simple: if you want to write less code that is more reliable, learn how to (and discipline yourself/team) to write the tests first! see: https://github.com/dwyl/learn-tdd https://github.com/dwyl/learn-tdd If you're stuck writing the tests for a feature/idea ask for help till it becomes natural! - Pre-commit Hooks: Make the tests, "linting" and doc checks run on the developers localhost before they can commit. See: https://github.com/dwyl/learn-pre-commit https://github.com/dwyl/learn-pre-commit If your tests "take too long to run" don't use it as an excuse to disable the pre-commit, fix it! Having slow tests (and build process in general) is a cancer that will gradually "sap" the productivity & energy of the team! Analogy: it's much more difficult to get physically fit if you are an obese "couch-potato" than if you simply maintain your fitness each day; "Unfit" Apps die young. - Code Analysis: If there is an automated tool for your chosen tech/tool/stack use it! Even if costs money, think of it as "member of the team" not an "expense". It will always save you time in the long run. - Continuous Integration: Pick a CI system based on your tech/tools and implement it for your app. it only takes a few minutes: https://github.com/dwyl/learn-travis https://github.com/dwyl/learn-travis - Code Review: Use GitHub Pull Requests (or the equivalent on BitBucket, GitLab, etc.) and leave helpful comments, besides pair-programming this is one of the best ways to learn as a team. - Continuous Delivery: When Pull Requests are merged, they should be automatically deployed! If the app/product/company is new, use Heroku for deploying your app! Don't waste time on DevOps till you need to! Migrating to AWS or GCP is easy once you have "traction" (i.e. if you're paying Heroku $200/month, you can justify orchestrating/managing you own DevOps/Infra). see: https://github.com/dwyl/learn-heroku https://github.com/dwyl/learn-heroku - Continuous User Testing: Ensure there is a clear process for testing the new features you are releasing. Ideally "get out of the building" and test with "real users" in person. see: https://steveblank.com/2010/03/11/teaching-entrepreneurship-%E2%80%93-by-getting-out-of-the-building https://steveblank.com/2010/03/11/teaching-entrepreneurship-... "weekly" should be the minimum user-testing cycle. No "excuses" to not test! Use online services like https://www.usertesting.com https://www.usertesting.com if you aren't physically near to your users. - Continuous & Validated Learning: Instil the habit/culture/expectation that everyone should keep learning. If people "stagnate" everyone suffers. The Product will be worse, the best people will get jaded and leave. Learning is easy to forget but it's just as easy to maintain, it's just a question of routine.
- viach 8y agoImplement or fix basic integration testing infrastructure. It is usually broken or doesn't exist.
- monk_e_boy 8y agoHahaha! Good lord. First I push for a DEBUGGER. Second I demand they test their backups. An untested backup is just a delightful wish. After months of push back for those two and I've made myself a hateful person to all involved I ask for ALL code to go into repos. Often there is a bunch of "Oh, my code doesn't need to go in, for reasons." No FUCKING NO, your code needs to go into a repo and needs reviewing. The boss needs all passwords. Okay, not your personal passwords, but if you're not in and you're sys-admin, we need to get into the f-ing box. You can not be the only person with a login. Create more users, give those users permissions. So many companies have one guy/gall who has access to some critical part of the puzzle and no one else knows how to even log into it, let alone all the hacky scripts that are needed to push a change live. Automatic testing. We almost got there in one company. So close... until one day they ran out of money. We found that an SQL statement wasn't coded right and we hadn't billed 50% of our customers. Ever. No a dime. Not a cent. Accounts never realised. Even in the early days when they only had ten or so customers. The billing record shows they only sent four bills out. Come on people.
- yjftsjthsd-h 8y agoI find it helpful to have a "misc" repo just for those weird not-quite-one-off scripts and the like that don't really fit into the main repos.
- tboyd47 8y agoThe first thing I do is fix bugs. It lets me know the types of problems that come up.
- majewsky 8y agoOne thing that I find sorely missing in many teams is onboarding documentation. So when you come in, document everything that you need to do (required permissions, development environment setup, mailinglists, subscriptions) and how to do it.
- wodenokoto 8y agoThis is a really good idea. Reminds me that I should finish up my onboarding notes and publish them internally
- mertnesvat 8y agoA good place to start, I did the same in the past.
- cwingrav 8y agoEvery new person on my teams, I have document what knowledge they are missing and what their questions are. We then fix and update the documents we have to address this. If you're on a growing team, this approach saves time/money in the long run.
- cgb223 8y agoThis is a great way to write the onboarding docs for the person who replaces you when you get laid off Happened to me...
- myth_buster 8y agoWe have a onboarding wiki page that has everything that's required on your first day to the day you getting your first code to master branch. We hand it to the new joinee and ask them to update it if they find something that wasn't documented. It has gone through so many reviews that in most cases that's all they require for a smooth onboarding.
- mwilliams11175 8y agoIt's either missing or if there's any documentation it's scattered all over the place and outdated.
- 8y ago
- jacquesm 8y agoProper logging, if they don't have it. Otherwise, take a hard bug and fix it.
- adyavanapalli 8y agoDo you know any resources for learning this?
- jacquesm 8y agoAny open source project with open bugs (that's most of them). Proper logging: that's a complex subject and it took me a good chunk of my career to figure that out.
- gwbas1c 8y agoI try to understand what the real problems are, and if there is the will to fix them. Then I try to understand the real social hierarchy and everyone's biases. In the last two jobs I've started, both had serious problems from using an ORM framework and dependency injection framework incorrectly. In one company, the project ended up going nowhere because of incorrect biases towards using a database. In the other company, everyone knew that if they didn't fix the problem, they'd go out of business. I left the company that didn't want to fix its code, and still work at the company that fixed its ORM and dependency injection problems. [Edit] The project that went nowhere failed because the lead programmers didn't know how to use a database. They wrapped it with layers of frameworks and code generators. The layers took so much time to work with that the schedule dragged out, and we missed our market opportunity. There was no will to fix the real problems, so ultimately I knew I had no future at the company.
- mkbkn 8y agoMandatory learning something related to the work. Either the company schedule professional classes for that or reimburse the equivalent amount of money if you self-learn. Assuming your employees to know everything and not let then learn is a path to your organization's downfall. Ben Horowitz makes a good case about it in his book The Hard Things About Hard Things
- aplummer 8y agoI'm a consultant, the biggest thing to understand is that you don't work for the company, you work for the individuals in the company. You need to immediately start solving what they think is the problem, to build the capital to solve their actual problem. Ex. Company thinks they need more developers to ship on time (you). First, make sure you're getting tickets done and helping them with the metrics they know, then change the process to fix them for good once you have their trust. If you skip to step 2, you've got someone angsty with a career on the line who 'isn't getting what they paid for'.
- _wmd 8y agoEverything here, but with an important tweak to step 1: it's impossible to know what needs fixed until you've actually gone through the motions of trying things as they are today. It's easy to come in pushing all your 'best practice', but any of it could be a bad idea in any particular scenario, and it's impossible to know without context I don't think I've introduced anything revolutionary in the last few places I've been (going back ~2 years+), and that's also a fine outcome. Often it turns out that causing disruption to something that works well enough is far more counterproductive than simply leaving things as they are. Save the churn for a big change that really provides an important benefit, otherwise it's not worth the time
- maxxxxx 8y agoI think the first thing you should implement is your own understanding of the current codebase and processes. I have seen it now several times that new guys come in and immediately push for their pet architecture without even trying to consider that we are not complete dummies and a lot of things are there for a reason or are at least not that easy to change. Usually it ends with them being rejected and then getting frustrated because they didn't get their way. On the other hand we also have people come in, help with the current codebase and after a while they make proposals for improvement that are based in reality. These people integrate well and are quickly respected team members.
- Matheo05 8y agoI am a bit surprised all the comments so far are tech or process oriented. On my side, I try to say "Good morning" to everyone and get to know them a bit better. It allows me to quickly identify the key resource I need to get answer and being friendly usually make them reply faster.
- lvh 8y agoLatacora perspective, AWS specifically: go install aws-vault. https://github.com/99designs/aws-vault https://github.com/99designs/aws-vault There are a ton of benefits to aws-vault. Strategically: getting everyone on an aws-vault workflow is step one to eventually making your IAM story great. We'll be publishing some general stuff about how we think you should start cleaning up your IAM story. We have Strong Opinions(TM) on how to get you from "bunch of people have * : * perms with keys they have on disk" to best-in-class, BeyondCorp-compliant temporary perms acquired on trustworthy endpoints. (FWIW: also undersigned re: start by listening. Latacora starts with an audit too, but that feels like a cop-out answer :))
- falcolas 8y agoOops. I was thinking of the wrong tool. Personally, my biggest peeve with temporary IAM credentials is the duration. Having them invalidate in the middle of a Packer build is a real mood killer. Our own company got them extended to 12 hours recently, which was a huge win in this department. Original content - about Secrets Manager: AWS Secrets Manager is stupidly expensive for a password manager that rotates passwords. It can't even rotate all passwords, just those for a specific subset of AWS services. Should instead start with parameter store (which is free but still offers encrypted password storage) and then figure out what parts really need a rotating password and that are operating with services which Vault can rotate passwords for - at which point you migrate only those.
- lvh 8y agoYou appear to be confusing aws-vault, a gratis and open source project that manages IAM credentials, with AWS Secrets Manager, a hosted AWS service that stores and manages secrets. I agree AWS Secrets Manager is overpriced but I doubt it's a major expenditure for anyone. You should probably just use KMS instead and dump the ciphertexts wherever you want. Parameter Store is a fine place for them.
- falcolas 8y agoI did. Clearing up. That said, it is a major expenditure when used as part of the automatic workflow. And parameter store has KMS encryption/decryption built-in. Alongside full IAM level isolation.
- motoawk 8y agoI always test the backup restore process. It's amazing how many times you find issues.
- deleted 8y ago[deleted]
- cozuya 8y ago(front end js) My new favorite tool is the ridiculously named husky package, which allows for configurable git hooks inside of package.json. Specifically what I'm doing now is precommit eslint and prettier, and prepush test:all i.e. people on my team will be unable to commit if they fail lint and unable to push if they fail unit tests. There's of course positives and negatives to this approach but the former significantly outweigh the later in my experience.
- zrobotics 8y agoAnd you do this in a new job? Introducing a linter the first week seems like a great way to make your new coworkers hate you. Sure, it's a good thing to do, but if your teammates aren't already using one then unilaterally introducing this into the commit process seems a little radical.
- cozuya 8y agoMy OP should have called out that I specifically let everyone know that I have no problem with them using git commit -n and git push --no-verify to get around it if they are in feature branches. But yes I implemented this on day.. 2 of my current position which was lead of a greenfield project.
- steve_adams_86 8y agoI've considered this because I love the idea. I just assume I'd start seeing tons of skipped tests, haha. "I'll fix that later".
- nmjohn 8y agoThis completely breaks a number of git workflows. In my opinion a better option is to have eslint / tests / prettier / etc run as part of CI, and have your pull requests require CI to pass before they can be merged. I like this balance better because the end goal is still met: "bad" code doesn't make it to the main git branch. But it also allows for git workflows which involve frequent commits. (If all tests have to pass for every commit, even locally when the commits may be rebased away, it encourages very large and hard to review commits instead of the smallest commit possible for the given changes.)
- emodendroket 8y agoI request good ergonomic equipment so I don't needlessly work in pain. Otherwise I'm pretty flexible.
- scarface74 8y ago#Tl;dr; Build relationships first, then build a reputation for your expertise, then implement changes. Just for context, I’ve been working as a professional software developer for 22 years, but I let my career and knowledge stagnate until 2007 and became an “expert beginner” (https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://daedtech.com/how-developers-stop-learning-rise-of-th...). I relaunched my career 11 years ago this month. So, how I’ve approached “what to change”, changed over the years... 2007 - started working at a small company. I took the job because they were looking for high level junior developers and were transistioning from VB6 to C# and they had a C++/MFC framework. It was the perfect position for me. I was really good at both their old technology and I was just getting into C#. I didn’t try to change anything. I took the job to get some real world modern development experience and soaked everything in. 2011 - that company went out of business but by then, I knew C#, I could talk the talk about modern software engineering practices but I still needed more experience. I got a job at a Fortune 10 (at the time) company and learned how modern large software teams and organizations worked and was there to learn, not to change things. I took what I learned and leveraged it and my by then 20 years of on paper experience to get a job where they wanted someone to make significant changes to a slow moving dysfunctional software development department.... Again: My goal wasn’t to make changes, it was to keep my head down, not ruffle feathers and learn. 2014 - With both my manager’s and his manager’s blessing, I along with the other developers they hired, went in and started trying to make changes in the CI/CD process, getting rid of some bespoke custom libraries that could be implemented better using popular Nuget packages, and changing the testing process like bulls in china shop completely disregarding the feelings of the old guard. Eventually the old guard won, pushing both managers out and leaving the new hires without any cover. Lessons learned: Build relationships first, respect the past decisions that got the company to where it is, and remember one of the “Laws of Power”, “Law 45: Preach the Need for Change But Never Reform Too Much at Once”. Try to win people over based on building relationships. 2016 - I started working at a new company with the official title of “Team Lead” where I was brought in to modernize the development department. I learned my lesson, first I built relationships, I respected the work the team did, engendered respect, and earned the loyalty of the team. Even though I had role power, I realized that wasn’t going to be effective without the relationship power. I implemented version control, a real CI/CD process, automated testing, documentation standards, fought to reduce needless meetings and fought for the “40 hour work week”. 2017: I got another job at a small company as “just” a senior developer and an equal on paper. I quickly started building relationships and proving my expertise. I have far more influence to make changes based solely on doing that than I have ever had before. Automation is always my hobby horse. First I implemented a sane CI/CD process and configuration management. The next thing I’ve worked on is getting rid of single points of failure in both systems and people - I’m encouraging cross trainings.
- soulnothing 8y agoDocumentation is my biggest thing. I start with onboarding, CI/CD. Then start adding api and archicture documentation. This forces me to learn, and ensure I digest well enough to explain to other people. Once that's done I start adding unit tests, monitoring, and additional dashboards.
- dood 8y agoDocumentation has some great properties as something to work on in early days (so long as you aren't immediately firefighting). * Documentation always sucks, no-one wants to do it, and everyone knows it has room for improvement. It shows you're willing to roll your sleeves up and do the less glamorous stuff. * Working on it prompts you to ask simple questions so is a good way to get to know people on the team, and in the process learn the history of the team, why things are the way they are, and where the dark corners are. * You're immediately creating value, rather than doing bugfixes no-one cares about or having meetings about things which are months away from fruition, and demonstrates you're here to make things better for everyone.
- bloopernova 8y agoOne of the first things I do, as a sysadmin/devops person, is to look at how "easy" it is to communicate. In other words, does this department have group chat, how easy is it to add documentation, how do I tell who is on call, am I being told things face to face or am I being walked through existing documentation? This is related to a lot of deep issues in operations or development, I feel. If the only documentation is fire and forget word documents in a windows shared drive, does anyone read them? Can I search for the information I need? Is the department ruled by one or two people who hold all the knowledge? Are all decisions made by those people, or are there people who never read emails and always demand face to face meetings to discuss issues? Communication is key. What you do and how you do it follows on from how, what, why information is shared.
- xaedes 8y agoHow do you improve communication issues when you discover them? For example suppose you encounter documentation by word documents in windows shared drive and an set up but not really used confluence (so we don't need to think in this example about setting up a system technically, but how to make people use it).
- KaiserPro 8y agoSingle Sign on. There is nothing worse than loads of different accounts that are all for the same person.
- yjftsjthsd-h 8y agoBonus points if the multitude of accounts don't map 1-1 to people. Sometimes an account is for a user, sometimes it's for a team, sometimes it was a user until they quit and it became a team account but still with the original employee's name. The accounts are all individually managed, of course, so getting access to something requires raising a ticket to the relevant team, then testing whether the account they gave you actually has permissions to do your job. But sometimes you find that they only gave you read-only access because only they can actually modify that cluster. Oh, and sometimes you find that an ex-employee only had maybe half of their accounts deactivated, and one of them has been recently used, and you have to find out whether you're looking at a security breach or just "recycled" account use. We use SSO now. It's nice.
- lloeki 8y agoI usually take a humble attitude as I pace myself into things and blend with the team, but the first thing I try to take care of is make sure the Joel Test is passed. It's amazing so many shops and companies seem content with a score of 2 or 3.
- Annatar 8y agoThe first thing I implement at a new company is configuration management using OS packaging.
- jtreminio 8y agoA Docker or Vagrant setup to match their prod as closely as possible, for local dev purposes. It boggles my mind how many developers _still_ install PHP/MySQL/Ruby/Node/etc on their daily desktop and are surprised when something doesn't work as expected on production.
- yeswecatan 8y agoDo you typically choose one over the other?
- digitalsushi 8y agoI'm not them, but for me I would use Docker if I am tearing the stack up more than a dozen times a day, and Vagrant if I am doing it less. I doubt I use either of them correctly. But I do love the way I use them.
- creatornator 8y agoSame. I generally try Docker first. With multi-stage builds, you can reduce container build times by a lot (after your first build), as opposed to reprovisioning an entire vm every time you need to nuke your dev environment and start from a fresh image.
- acconrad 8y agoThe very first thing I do is update documentation. You're a fresh set of eyes and so documentation for onboarding, setup, and building the application on your laptop is the kind of thing that often goes by the waist side. Did a step not work because you've updated your OS? Was there a critical typo in the terminal? These things provide immediate value to all future hires.
- delinka 8y ago...by the wayside
- codingdave 8y agoThe first thing I want to see is a culture where people listen to others and understand where everyone is coming from before pushing their own agendas.
- ryandrake 8y agoI once joined a company and found out on day 1 that they had: 1. No source control system 2. No bug/issue tracker (or formal software QA) 3. No build automation 4. No dedicated build system 5. No pre-launch checklists Basically, the latest release was whatever happened to be on one of the engineer's hard drives whenever someone frantically ran in and said "we needed to release!" You can imagine how fun it was to repro when customers reported bugs. And they did, Gandalf, they DID... Those were the first things to address because they were obvious gaping wounds and I could implement them myself without really having to convince anyone. The CEO thought they were a waste of my time (I hired you to write codes) but didn't actually stop me from setting them up. The next things lacking would take more effort to fix because they were people/process dependent: like no code reviews, no software development process, no bug triage process, etc.
- JBReefer 8y agoHow long did you last? I worked somewhere like that, most engineers lasted 3 months, I managed to squeeze out 4! Places with issues like that tend to have TONS of other very serious issues.
- ryandrake 8y agoYou guessed right. Turnover was a huge problem too. I lasted just over a year, and only because it was during the depth of dot.com recession 2.0 and there weren’t exactly jobs available on every street corner. The technical problems were merely symptoms of structural and leadership problems.
- deleted 8y ago[deleted]
- marcodave 8y agoBasically you just described the situation at my first workplace in 2007. To be fair it wasn't a software company, and most of the software was for internal use. Still. The first proper installation of SVN happened only in 2010...
- tty89 8y ago
- fragileScrump 8y agoBasically, when I ask for a role, whereby I expect to be placed in charge of the project, I expect exactly that. Not some fluffy title, with a cushy salary. I expect to be able to destroy the scrum process, hang the scrum master. Toss agile in the garbage. Ask the product owner what they actually want. Do that, in about a month. Finish the project 6 months ahead of schedule single-handedly, because web apps are fucking easy. At that point I get to make doing nothing look like my job, because I put myself ahead of the game. Finishing in weeks, what would have taken months of multiple people wanking a daily stand-up ritual every fucking morning. While other people waste time on acts of contrition, defending their thesis from hecklers in a public square, I'm getting shit done, making computers do my bidding. (not people) But no. It doesn't always work like this. And sometimes you just have to quit so fast that you make some dipshit's head spin. Because he was so fucking caught up in how to make the perfect outlook invitation, by clicking the proper button in skype. Fuck stand-ups. Fuck one-on-ones. Fuck code reviews. Fuck performance reviews. Concentrate on working in a library as silent as a tomb, and fucking destroy shit. That's how programming works.
- raziel2p 8y agoYou sound like a horrible coworker and employee.
- fragileScrump 8y agoYou sound like the peanut gallery of an open web forum on the internet.
- dang 8y agoPersonal attacks are not allowed here, regardless of how badly someone else behaves, so please remain civil. When another commenter behaves egregiously, flag the comments or email us (hn@ycombinator.com) instead. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- lolsal 8y agoYour attitude (if not sarcastic, maybe I missed the clues) makes me think you have not ever worked at a large company or on software that is more complex than a CRUD application.
- tibbon 8y agoI work on Ruby 95% of the time. If there's no well-configured Rubocop setup, I get that into place as my first order of business almost immediately.
- lgleason 8y agoIt depends on the project. The biggest thing is to assess where the team is at. I just left a project where the team had serious issues and the leadership did not have the desire to fix it...IE: a tech lead that was more of a mid level dev running a command and control style thing. The team, with more experience, did not have a say in the architecture, what they got to work on etc.. All devs had to get their commits past the mid-level lead, the lead would reserve most of the fun and hard stuff for themselves and leave the scraps for the rest of the team. The lead had multiple silo'ed efforts and, as a result, had a higher number of commits etc. on code base partially because they were constantly declining PR's from the rest of the team to do it their way. Now if you have a team that is actually open to your ideas things are VERY different. I've worked on them and they are amazing. The key thing is to evaluate where they are at and apply what is going to work for them. The biggest thing is to avoid the one size fits all approach. With the original comment for this thread, my biggest issue out that gate with their approach is that you are using a lot of branches which negates the benefits of CI etc.. Why not instead try to figure out how to reduce branches and have more people checking in working code to dev with unit tests?
- lvh 8y agoLatacora, corpsec perspective: audit Google Groups and OAuth'd apps, run a phishing red-team exercise. Finding appsec bugs matters but maybe not so much if everyone just signs over whatever privilege apps ask for and it'll exfil whatever's on Drive.
- beat 8y agoI job-hop a lot in corporate environments (mostly Fortune 100), doing DevOps for legacy systems/teams rather than coding. As such, I don't push for anything when I first arrive. It can take a while to understand how all the moving parts interact, both technically and organizationally. The systems in question are sometimes responsible for tens or even hundreds of millions of dollars in business, and critical corporate functions. Wading in with "Hey, I know more than you, stop doing that and do this instead" is the short path to sudden emergency downtime for production systems! And that's knowing they hired me because I'm the expert and know more than them. So there will be processes that are really, really stupid. Slow, inefficient, maybe completely dysfunctional. But if they work, they work. Fixing/replacing them means interactions with other processes that can be very difficult to pull off. Process is usually a Big Ball of Mud Antipattern at the point I'm brought in, and fixing anything in the Big Ball of Mud is a challenge. As for legacy apps... yes, built with antiquated technology, often poorly implemented, with a lot of uncertainty and fear. Change is really scary. What to do about this stuff depends on what the long-term vision for the product is. Is it in maintenance mode, or under active development? Is there a plan to replace it? Is there a realistic plan to replace it that has working results and a viable schedule? Generally, the best thing to do is leave the scary ugly thing alone. It was probably done pretty well back in its day. Where I usually find myself making progress early on is finding things that are broken due to communication problems. One team says one thing, the other team says another, and everyone is mad and nothing gets done. Often, it's just a matter of rephrasing things to both teams, to find common ground and a way forward that everyone wants. So really, my expertise isn't cool tech. It's being a good communicator on the engineering rather than the management side, someone with both development and operations experience who can speak to the concerns of both sides, and has seen similar problems in other organizations (big organizations like these usually have 10+ year people in key positions, who have no idea how the rest of the industry works anymore). So yeah, the first thing I push for? Learning the lay of the land, so I can start charting paths.
- stuntkite 8y agoAuth. If you can stomach it, back it up with a real directory service. JumpCloud is a great way to do it. It's free up to 10 users. You can use it with Google Hosted Apps as your user backend. You can set it up in 10 minutes. It has TONS of features, you probably won't look at them all once you can use it as an SSO/LDAP provider, you can forget about all that until you need more. Also you can easily replace it with something self hosted if you grow to the point of needing to do something else. Determine if you need organization level RBAC (Role Based Access Control). Does your app need to have account managers at the customer level? You probably know from the outset if you'll face this problem. It's a big pain if you get someone to implement your product somewhere, then they lose that person and they have trouble accessing their account. Not that you can't provide support to solve it, but the legal side can get tricky and no matter what you lose face with the customer over the frustration. DockerHub messed this up IMO and that's why they haven't added it, because it's too complicated to add now. You can easily have a simple SSO layer on top of it so your super admins come from the LDAP(or other) and user/customers are a separate DB in your existing app. It can be really expensive to add complex auth or change how it works later, but a stitch in time makes it easy to grow and adapt. This helps tremendously for DevOps, deployment security, managing things like white label licenses, and a host of other things. Once you have it, it keeps you from writing terrible solutions to dance around having things like user account profiles. API keys if you need to offer them become easier and control of important assets are much less scary. Also you are ready to implement things like IAM management or whatever to keep track of deployment keys before you end up with a giant pile of security holes. JumpCloud offers a pretty turnkey IAM integration for AWS and others. After that, getting paid. Figure out how to take money as fast as possible with the least friction. If you have auth and the ability to take money easy, pivots come a lot easier too. Since you have proper auth, things like subscription management becomes an easy reality without leaning on 3rd party vendors. Though just using stripe for that can be good enough, still you'll need to tie it to accounts. Especially if it's enterprise. Something I've done recently that is now a part of my "get started fast" kit is automated DNS and TLS (via letsencrypt) with kubernetes. Might not be for everyone, but now that I'm on the other side, I'm not going back. I can tie a feature branch deploy via helm chart to it's own DNS endpoint defined as the host in the config, protect the ingress via LDAP, and make sure QA has an endpoint to review that won't be interrupted until the ticket is closed. One command and it's deployed and secure. Also this enables devs to deploy their own workspaces for effortless experimentation without disrupting dev/staging/prod, which shouldn't be used as sandboxes for features or QA IMO. * http://www.jumpcloud.com http://www.jumpcloud.com * https://www.keycloak.org/ https://www.keycloak.org/ * https://github.com/kubernetes/charts/tree/master/stable/external-dns https://github.com/kubernetes/charts/tree/master/stable/exte... * https://github.com/kubernetes/charts/tree/master/stable/cert-manager https://github.com/kubernetes/charts/tree/master/stable/cert... * https://github.com/kubernetes/charts/tree/master/incubator/keycloak-proxy https://github.com/kubernetes/charts/tree/master/incubator/k...
- chandmk 8y agoJoining a new company is like starting a new life, which doesn't seem to happen many times in a life time. It is like you are being given another opportunity to start fresh. First thing then to do is gain respect, learn the culture. It is going to be uncomfortable for a while, so it is important to keep the opinions under check. Let the actions speak more than words. Remember that every design issue is a choice made by someone else to the best of their abilities. Finding a way to move forward without making too much splash automatically unlocks the doors. There will be lot of things to implement and you will find a way and while doing so you will learn a lot.
- linsomniac 8y agoI mostly do ops rather than dev, but: First, is anything broken? Any RAID arrays that are degraded or failed (yes, I've come into shops where that was the case). That sort of thing. Are systems secure? Are updates applied? What sort of network security is there? If there are known holes, has anyone compromised the system? Monitoring, how do we know something is having problems before the phone starts ringing?
- wcr3 8y agomy absolute dominance.
- sysbell 8y agoInternal URL shortener, every single time. They get rave reviews and in one case ended up being considered a core service that had to be up.
- jamestimmins 8y agoCan you explain what the purpose/benefit of this is?
- insomniacity 8y agoIt turns a mess of internal sharepoint/wiki/confluence links into an easily memorable namespace that can be 'linked to' verbally or on post-it notes. A common hostname is 'go', so when you launch some new programme, project or tool, you can put 'go/projectname', or 'go/toolname' in places like chat topics, email footers and presentation slides. Applicable in larger places that end up with a mess of different documentation systems, and where trying to unify everything would be a waste of time.
- goldhand 8y agoA eslint-config for the team! I get that setup with a style guide during the down time of the allotted "onboarding" phase.
- maerF0x0 8y agoI often walk through the Joel Test with sharply declining urgency ... That is I more or less demand source control, work on automated builds/tests (on each commit, not daily), start to log everything I see in JIRA (or another tracker), Look for an up to date schedule (ie, discern business priorities and timelines), attempt to start specifying how future things ought to work, train my coworkers to see when I'm wearing earplugs to drown out their non work related chatter.... https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
- viggity 8y agoI am usually new to the business domain, ergo, I start compiling a "Dummy's Guide to [Plant Genetics]" or whatnot. The code and the tools used to work on the problem domain are always changing, but the basics of the business usually are not. My guides help new hires understand why the business does what it does so they can start adding value more quickly.
- golergka 8y agoLead developer here, commonly brought in to overtake projects. Proper workflow for the team is the most important thing: make sure that each team member has an easy and unintrusive algorithm or picking small tasks, completing them and relaying them to the next one responsible makes team morale and planning a lot easier.
- tynecomputers 8y ago$3500+ for business travel UK/USA vs $800 for economy. I always get companies to offer the employee half the difference to fly cheap. Win Win!
- CodeWriter23 8y agoI’m a consultant. Honestly, I identity a good source of decent coffee, even if it means packing some at home. A reasonably comfortable chair. And if the temp is out of my comfort zone, I’ll pick up a desk fan. Making sure my creature comforts are in place helps ensure my productivity. Also, on my way out I ask the most helpful person if they’d like the fan and leave it with them. A calling card of sorts.
- walshemj 8y agoas a job hopper and " contractor" unless you have been explicitly brought in to set up better processes id STFU.
- twic 8y ago> a good feature-branch flow Ain't no such animal. https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/
- UK-Al05 8y agoTrunk based development is a feature branch flow. What do you think your local copy logically is?
- noir_lord 8y agoProper (as in working and recoverable..tested to be recoverable under the worst case I could think off) backups. I wish I was kidding but the last 'complete' back up they had was from mid-2014 (and the system was still in initial development from 2013 late 2016), I started June 2017. Outsourced development company (and bad developers and..well stuff I'd never seen before, RAID on the server but only 1 disk in use, 64bit Xeon's running 32bit Debian...and on and on it went - A backup server that had nothing on it..I mean literally nothing, the entire system runs as root (because the way to solve your inability to understanding the linux permission model is just to run everything as root apparently).
- lowlevel 8y agoFraud prevention, gate keepers.
- nojvek 8y agoSpend time talking to people, learning what the hard and hairy problems are. Playing with product and getting a feel for what customers experience. Dabbling in code, trying to make a mental architectural map and asking coworkers to validate assumptions. “What happens when someone does X?” questions. First week is lots and lots of asking noob questions and documenting them if it’s not already done.
- calciphus 8y agoI'm a product manager, so I'll vary a bit from the development-specific things already listed. Basically, when I get a new product line (or company), it goes the same way: 1. Gather hate mail. Find whatever complaints you can about the product and team you've just inherited. 2. Use the product. Try and break it. Act like an angry QA engineer. 3. Find the person or people who support customers on the product. Ask them what makes their job suck. Ask what's broken. 4. Ask them why they think it sucks / is broken - preferably outside the office (coffee, lunch, etc). 5. Meet dev team. Ask them why the product matters. Gauge their interest and understanding of the problem and customers. Ask what they think is important to address as a team. 6. Combine answers to 3-5, identify common threads. Look for places where there are common blocking factors (cost, time, focus, politics, history). 7. Find something to work on with the team, that can be delivered fast. Talk about what you want to do with support folks (from q3). Sanity check, make sure dev team understands the value of what they are working on. 8. Check in with superiors. Make sure you understand what's important to them. Talk about what you've heard. I've found I can't come in and expect to be an expert in a given area overnight. But I can be good at asking questions and spotting painful things. (edit: formatting)
- anotheryou 8y agoif there are smokers, join their breaks. it's a good way to learn about culture, history and customs of a team.
- Adamantcheese 8y agoDelete as many things as possible without breaking anything. Lots of crap tends to build up and nobody wants to keep lugging around several hundred megabytes of useless auto generated build garbage.
- garfieldnate 8y agoI start creating a glossary of all of the unique and important terms and concepts used by my team. This is a great way to confirm understanding and becomes great documentation for the next person to join.